일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 백준 1167 트리의 지름 파이썬
- 가장 긴 팰린드롬 파이썬
- 백준 1034 램프 파이썬
- 백준 2146 다리 만들기
- 트리의 지름 파이썬
- 프로그래머스 여행경로
- 프로그래머스 순위
- 백준 1613 역사
- 반도체 설계 파이썬
- 다리 만들기 파이썬
- 백준 2352 반도체 설계 파이썬
- SQL SERVER MIGRATION
- 베스트앨범 파이썬
- 프로그래머스 등굣길
- 프로그래머스 가장 긴 팰린드롬
- 백준 1516 게임 개발
- 백준 1238 파티 파이썬
- 등굣길 파이썬
- 프로그래머스 순위 파이썬
- 다중 컬럼 NOT IN
- 순위 파이썬
- SWEA
- 램프 파이썬
- 게임 개발 파이썬
- 역사 파이썬
- 가장 긴 바이토닉 부분 수열 파이썬
- 백준 1043 거짓말 파이썬
- 프로그래머스 베스트앨범
- SQL SERVER 장비교체
- 백준 11054.가장 긴 바이토닉 부분 수열
- Today
- Total
공부, 기록
[Aurora] Commit 지연 지표 본문
서비스를 모니터링 하는 중 Aurora PostgreSQL 성능 개선 도우미에 DBLoad 가 증가하고 지연 값으로는 IO:XactSync 가 잡히며 해당하는 쿼리는 COMMIT 만 찍히는 상황이 발생하여 이를 케이스 오픈을 진행해가면서 상세하게 확인하고자 하였습니다.
먼저 해당 지표는 Aurora 문서에서 다음과 같이 설명되어있습니다.
IO:XactSync 이벤트는 데이터베이스가 Aurora 스토리지 하위 시스템이 일반 트랜잭션의 커밋을 승인하거나 준비된 트랜잭션(Prepared Transcation)의 커밋 또는 롤백을 확인할 때까지 대기 중일 때 발생합니다. 준비된 트랜잭션은 PostgreSQL의 2단계 커밋 지원의 일부입니다.
해당 지표가 발생하는 원인은 다음과 같습니다.
Onpremise 환경의 데이터베이스에서는 일반적인 트랜잭션에서는 WAL 에 데이터가 작성이 되고 COMMIT이 발생하는데 Aurora는 자체적인 스토리지 구조를 가져 이를 다음과 같은 프로세스로 처리합니다.
- 인스턴스의 버퍼에 WAL에 데이터가 작성이되고 Commit이 발생하면 스토리지 노드의 메모리 영역에 있는 INCOMING QUEUE로 LOG RECORDS를 전송합니다.
- INCOMING QUEUE 에서는 스토리지 노드의 물리 영역인 UPDATE QUEUE로 LOG RECORED를 전송합니다
- 스토리지 노드는 PRIMARY NODE에 COMMIT이 완료되었다는 ACK를 전송합니다.
위의 단계의 프로세스가 IO:XactSync 지표 지연 동안의 작업이라고 합니다.
Aurora MySQL도 이와 동일한 프로세스로 진행이 되며 io/redo_log_flush 지연 지표가 트랜잭션의 완료를 대기하는 점에서 비슷한 역할을 하는 지표 입니다.
즉 위의 지표는 Aurora Storage 자체의 지연으로 별도 튜닝이 어려운 상황입니다. 다만 위 같은 상황을 개선하는 방법으로는 여러 횟수로 요청되는 COMMIT을 분산하여 요청하는 방식의 개발 단계에서의 튜닝이 필요합니다.
'공부 > DATABASE' 카테고리의 다른 글
[MySQL] MySQL group by 개선 (0) | 2024.11.28 |
---|---|
[AWS] Aurora, ElastiCache 타입 변경 스크립트 (0) | 2024.11.21 |
SQL Server와 MySQL만 하다가 PostgreSQL을 공부하니.. (0) | 2024.10.15 |
Valkey의 멀티스레드 아키텍처 (0) | 2024.10.12 |
[AWS] DynamoDB (0) | 2024.09.15 |