Amazon RDS for PostgreSQL 인스턴스를 버전 11 이상으로 업그레이드한 후 5분마다 쓰기 지연 시간이 갑자기 증가하는 이유는 무엇인가요?

3분 분량
0

PostgreSQL용 Amazon Relational Database Service(RDS)를 버전 11 이상으로 업그레이드했습니다. Amazon CloudWatch에서 5분마다 쓰기 지연 시간이 급증하는 것을 볼 수 있습니다.

해결 방법

유휴 Amazon RDS for PostgreSQL 인스턴스를 사용하면 5분마다 Amazon CloudWatch 메트릭 쓰기 지연 시간이 급증하는 것을 확인할 수 있습니다. 이는 PostgreSQL 버전 11 이상으로 업그레이드한 후 향상된 모니터링 메트릭 쓰기 전체가 약 64MB로 급증하는 것과 관련이 있습니다. wal_segment_size 매개 변수의 값은 업그레이드 후 64MB가 됩니다. 버전 10 이하에서는 wal_segment_size의 값이 16MB이므로 이러한 급증이 눈에 띄지 않을 수 있습니다. 자세한 내용은 2018년 9월 7일 Amazon RDS - 문서 기록의 업데이트를 참조하세요.

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

#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 요청이 있는 바쁜 시스템에서는 이러한 모든 요청에서 평균 지연 시간이 계산됩니다.

이러한 경우, 유휴 상태의 유휴 Amazon RDS for PostgreSQL 시스템에서 5분마다 쓰기 지연 시간이 급증하는 것을 볼 수 있습니다. 데이터베이스 인스턴스가 바쁜 워크로드를 실행하는 경우에는 이러한 스파이크가 표시되지 않을 수 있습니다.

예시: 두 개의 t2.small Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 각각 8개의 gp2 볼륨을 가지고 있다고 가정합니다.

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를 파일 이름으로 바꿉니다.

두 번째 EC2 인스턴스가 첫 번째 EC2 인스턴스보다 CloudWatch에서 더 높은 작성자 대기 시간 급증을 보여줄 수 있습니다.

관련 정보

PostgreSQL 작업 모범 사례