Amazon RDS for PostgreSQL 인스턴스를 버전 11 이상으로 업그레이드한 후 5분마다 쓰기 지연 시간 스파이크가 표시되는 이유는 무엇입니까?

해결 방법

유휴 상태인 Amazon Relational Database Service(Amazon RDS) for PostgreSQL 인스턴스를 사용하면 5분마다 Amazon CloudWatch 지표의 쓰기 지연 시간에 스파이크가 발생하는 것을 알 수 있습니다. 이 스파이크는 PostgreSQL 버전 11 이상으로 업그레이드한 후 향상된 모니터링 지표 쓰기 총계의 스파이크가 약 64MB로 증가한 것과 관련이 있습니다. wal_segment_size 파라미터의 값이 업그레이드 후 64MB가 됩니다. 버전 10 및 그 이전 버전에서는wal_segment_size 값이 16MB이기 때문에 이러한 스파이크가 눈에 띄지 않을 수 있습니다. 자세한 내용은 Amazon RDS - 문서 기록에서 2018년 9월 7일 업데이트를 참조하세요.

PostgreSQL용 RDS의 archive_timeout 구성은 5분으로 설정되어 있습니다. 이 설정은 아카이브 프로세스가 아카이브할 로그 선행 기입(WAL) 세그먼트를 Amazon Simple Storage Service(Amazon S3)에 5분마다 복사한다는 의미입니다. 유휴 시스템에서는 일반적으로 이 복사 프로세스가 유일한 I/O 작업이므로 CloudWatch 그래프에서 이 작업이 각별히 우세해 보일 수 있습니다. 그러나 사용량이 많은 시스템에서는 이 패턴이 표시되지 않을 수 있습니다. 예를 들어 db.t3.small 인스턴스에서 30분 동안 다음 워크로드를 실행하여 20GB Amazon Elastic Block Store(Amazon EBS) 볼륨이 있는 PostgreSQL용 RDS 인스턴스에서 사용량이 많은 시스템을 시뮬레이션한다고 가정해 보겠습니다.

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

이 워크로드에서는 CloudWatch 쓰기 지연 시간 지표에 스파이크가 나타나지 않습니다.

하지만 다음과 같은 사용 사례가 있다고 가정해봅시다.

• 완료하는 데 10밀리초가 걸리는 I/O 요청과 완료하는 데 각각 1밀리초가 걸리는 9개의 다른 I/O 요청이 있습니다. 이러한 요청의 평균 지연 시간은 다음과 같이 계산됩니다.
  평균 대기 시간=(10+(9*1))/10=1.9밀리초
• 완료하는 데 10밀리초가 걸리는 I/O 요청이 있고 다른 I/O 요청은 없습니다. 이 경우 평균 대기 시간은 다음과 같이 계산됩니다.
  평균 대기 시간=10/1=10밀리초

두 사용 사례 모두 완료하는 데 10밀리초가 걸리는 동일한 I/O 요청을 포함합니다. 그러나 평균 지연 시간을 계산할 때, 느린 요청은 느린 요청과 함께 실행되는 I/O 요청 수가 적은 두 번째 사용 사례에서 두드러집니다. 유휴 시스템에서 블록 크기가 커서 느린 I/O 요청이 하나 있는 경우 지연 시간은 이 요청에서만 계산됩니다. I/O 요청이 여러 개 있고 대부분 블록 크기가 작은 시스템에서는 평균 지연 시간이 이러한 모든 요청에서 계산됩니다.

이런 경우 PostgreSQL 시스템용 유휴 RDS에서 5분마다 쓰기 지연 시간 스파이크가 표시될 수 있습니다. 데이터베이스 인스턴스에서 사용량이 많은 워크로드를 실행하는 경우 이러한 스파이크가 표시되지 않을 수 있습니다.

예: 각각 8개의 gp2 볼륨이 있는 두 개의 t2.small Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 있다고 가정해 보겠습니다.

crontab에서 다음 명령을 실행하여 첫 번째 Amazon EC2 인스턴스에서 5분마다 블록 크기가 64MB인 64MB 파일을 생성합니다.

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

참고: 명령의 big_file.txt를 본인의 파일 이름으로 바꿔야 합니다.

또한 crontab에서 다음 명령을 실행하여 두 번째 Amazon EC2 인스턴스에서 1분마다 블록 크기가 8KB인 파일 100개를 생성합니다.

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

참고: 명령의 small_file.txt를 본인의 파일 이름으로 바꿔야 합니다.

CloudWatch에서 두 번째 EC2 인스턴스는 첫 번째 EC2 인스턴스보다 작성기 지연 시간 스파이크가 더 높다는 것을 알 수 있습니다.

---

관련 정보

PostgreSQL 사용 모범 사례