Database/PostgresSQL3 @Transactional 안에서 다른 DB를 호출했더니 — idle-in-transaction 7.54분 TL;DR- 증상: Grafana DB Connection Hold Time Max가 1시간 안에 8번 튐. 최대 7.54분. 반면 avg는 5~20ms 정상.- 처음 본 단서: avg는 정상이고 max만 튀는 패턴 — 전체가 느려진 게 아니라 '1개 트랜잭션이 커넥션을 독점'하는 형태.- 진짜 원인: @Transactional이 메인 DB(HikariPool-1) 커넥션을 잡은 상태에서, 메서드 안에서 *다른 DataSource*(서브 DB, HikariPool-2)를 10스레드 × 14배치로 병렬 조회. 그동안 메인 DB 커넥션은 쿼리 없이 트랜잭션만 열어두고 대기 → PostgreSQL 입장에서 'idle in transac.. 2026. 5. 26. Hibernate LockAcquisitionException인데 lock 경합이 아니었다 — PostgreSQL 40001과 슬로우 쿼리의 합작 TL;DR- 증상: 뉴스 목록 API가 평소 2~3초 슬로우, 가끔 SQLSTATE 40001로 실패- 처음 의심: Hibernate가 LockAcquisitionException으로 매핑 → 트랜잭션 lock 경합- 진짜 원인: lock 경합 아님. PostgreSQL Replica의 recovery conflict → 조건 1: Replica에서 슬로우 쿼리 실행 중 (수 초 이상) → 조건 2: Main DB에서 동일 테이블 대량 INSERT/UPDATE + VACUUM → 두 조건이 겹치면 max_standby_streaming_delay(30s) 초과 → replica가 쿼리 강제 종료 → 40001- 해결: (1) 파티션 pruning 활성화로 .. 2026. 5. 13. API는 504, replica DB는 EOF — PostgreSQL Hang 쿼리의 후폭풍 TL;DR- 증상: 한 서비스에선 504 Gateway Timeout, 다른 서비스에선 replica DB 커넥션 강제 종료(EOF)- 처음 본 단서: pg_stat_activity에 13시간 이상 active 상태인 SELECT 쿼리 2개- 진짜 원인: 13시간 hang 쿼리가 오래된 XID를 잡고 있어서 autovacuum 무력화 → dead tuple 누적 (일부 테이블 dead_pct 5,704%) → 테이블 bloat → 일반 쿼리 성능 급락 → 504 → primary가 vacuum WAL을 replica에 보내면 lock conflict → max_standby_streaming_delay 초과 → replica가 backend.. 2026. 5. 7. 이전 1 다음