요약: SQL 응답이 늦다고 항상 실행 계획이나 디스크가 원인은 아니다. 잠금을 기다리는 세션과 이를 막는 세션을 구분해 조사하는 조회 예시를 소개한다.문제와 배경CPU 사용률은 낮은데 SQL이 끝나지 않는다면 다른 트랜잭션의 잠금 해제를 기다리는 상황일 수 있다. 대기 세션만 확인하면 원인을 가진 세션을 놓치기 쉽다.핵심 내용PostgreSQL 공식 문서는 차단 관계를 직접 복잡하게 조합하기보다 pg_blocking_pids()를 활용하도록 안내한다. 이 함수로 차단 PID를 찾고 pg_stat_activity와 연결하면 세션 상태를 조사할 수 있다. 아래 예시는 PostgreSQL 18 공식 문서를 기준으로 한다.실무 SQL 예시먼저 버전을 확인한다.SHOW server_version;잠금 대기 세션..
글 읽기요약사용되지 않는 physical·logical replication slot은 WAL을 계속 보존해 pg_wal 파일시스템을 가득 채울 수 있습니다. 슬롯별 활성 여부·보존량과 소비자를 확인하고 한도 설정은 복제 재구축 위험을 평가한 뒤 적용합니다.문제와 배경복제 슬롯은 소비자가 중단돼도 필요한 WAL을 남겨 재연결을 돕습니다. 소비자가 장기간 멈추면 삭제되지 않는 WAL 때문에 디스크가 고갈될 수 있습니다. max_slot_wal_keep_size 기본값 -1은 슬롯의 WAL 보존 한도를 두지 않는 설정입니다.슬롯 상태 확인아래는 wal_status와 safe_wal_size를 지원하는 버전의 예시입니다. 먼저 SELECT version();으로 버전을 확인합니다.SELECT slot_name, sl..
글 읽기요약PostgreSQL 인덱스가 비대해졌거나 손상이 의심될 때 일반 REINDEX는 업무 쿼리를 오래 차단할 수 있습니다. REINDEX CONCURRENTLY의 사전 점검, 진행률 모니터링과 실패 후 잔여 인덱스 처리 방법을 설명합니다.문제와 배경재구성이 필요한 대표 상황은 대량 삭제·갱신 후 인덱스 비대, 손상 오류, collation 또는 ICU 변경, 지속적인 조회 성능 저하, INVALID 인덱스 발견입니다. 운영 중 영향도를 낮추려면 지원 버전과 대상에서 CONCURRENTLY 사용을 검토합니다.사전 점검SELECT version();SHOW server_version;SELECT i.indexrelid::regclass AS index_name, i.indrelid::regclass AS..
글 읽기요약: 단일 쿼리의 실행시간만 보면 짧지만 매우 자주 실행되는 SQL의 부하를 놓치기 쉽습니다. pg_stat_statements를 사용하면 호출 횟수, 평균·누적 실행시간과 블록 읽기량을 기준으로 개선 대상을 선정할 수 있습니다.문제와 배경현재 실행 중인 SQL만 확인하면 이미 끝난 쿼리나 반복 실행되는 짧은 SQL을 놓칠 수 있습니다. 5초짜리 SQL 한 번보다 20ms짜리 SQL이 수십만 번 실행될 때 더 큰 부하가 발생할 수 있습니다.핵심 지표calls: 실행 횟수total_exec_time: 누적 실행시간mean_exec_time: 평균 실행시간rows: 처리 행 수shared_blks_hit: 공유 버퍼 적중 블록shared_blks_read: 디스크 읽기 블록temp_blks_written:..
글 읽기