체크포인트를 잘게 나눠 고르게, 트랜잭션 로그(redo 로그, WAL)를 넉넉하게, 빠른 디스크.
그래프에서는
일정 주기로 튐 · DB 쿼리 지연, 디스크 쓰기량
확인할 곳
PostgreSQL은 log_checkpoints(최근 버전은 기본으로 켜짐) 로그의 체크포인트 시각과 쓴 버퍼 수, 체크포인트 횟수(17 이후 pg_stat_checkpointer의 num_timed·num_requested, 16 이하 pg_stat_bgwriter의 checkpoints_timed·checkpoints_req), checkpoint_warning 경고를 봄. MySQL은 SHOW ENGINE INNODB STATUS의 LOG 섹션에서 Log sequence number와 Last checkpoint at의 차이를 봄. 서버의 디스크 쓰기량·쓰기 지연을 함께 겹침
이러면 맞음
쿼리 지연이 튄 시각이 체크포인트 시각과 겹치고 그때 디스크 쓰기량과 쓰기 지연이 솟음. PostgreSQL에서 요청 체크포인트(num_requested)가 시간 체크포인트(num_timed)보다 훨씬 많으면 WAL이 max_wal_size에 자주 닿아 체크포인트가 앞당겨지는 것으로 봄
이러면 아님
체크포인트 시각과 무관한 주기로 튀면 백업·배치(dk-backup, db-batch)
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
변경 기록을 담는 트랜잭션 로그(MySQL의 redo 로그, PostgreSQL의 WAL)를 너무 작게 잡으면, 로그가 찰 때마다 DB가 급하게 체크포인트를 몰아 하느라 쓰기 처리량이 잠깐씩 크게 떨어집니다.
출처
WAL Configuration (PostgreSQL Documentation)PostgreSQL 체크포인트는 기본 5분 또는 WAL 1GB(max_wal_size)마다, 더티 페이지를 모두 써서 비쌈. checkpoint_completion_target으로 쓰기를 나눠 I/O 폭주를 피함. 체크포인트 간격이 checkpoint_warning보다 짧으면 max_wal_size를 늘리라는 경고를 로그에 남김