• 목차

<aside> 💡

요약

• 증상
  • 특정 시간대(토요일 새벽) image 테이블 Lock wait 발생
  • 다른 트랜잭션들이 특정 트랜잭션(블로커) 때문에 대기 상태로 쌓임
• 결론
  • 특정 트랜잭션이 image 테이블의 PRIMARY 레코드(X) 락을 대량(약 XXX 만 건) 점유한 채 유지
  • 블로커 세션은 Sleep 상태처럼 보이지만 autocommit=OFF || 트랜잭션 ACTIVE 확인 → 커밋 길어짐 (장시간 트랜잭션)
• 원인(추정 → 물증 확정)
  • Quartz 토요일 00:00에 시작되는 이미지 점검 배치(ImageCheck)가 서비스 AOP 트랜잭션 범위에 포함
    • 점검 대상 : image 전체 ( 수천만 건 )
      • HTTP HEAD 체크(I/O) + 반복 UPDATE가 하나의 긴 트랜잭션으로 묶임
      • UPDATE 로 잡힌 row lock이 배치 종료/커밋 전까지 누적 유지 </aside>

01. 배경

• DB Lock wait 이슈가 특정 요일/시간대(토요일 새벽) 간헐적 발생
• 평일에는 재현이 어려워 “심증”만 있었으나, 토요일 새벽 04:30 실시간으로 락 상태를 확인했고 결과적으로 “심증 → 물증”을 확보

02. 발생 조건 (특이점)

Quartz 스케줄 (토요일 00:00 실행)

<bean id="imageCheckServiceJobTrigger"
      class="org.springframework.scheduling.quartz.CronTriggerFactoryBean"
      p:jobDetail-ref="imageCheckServiceJob"
      p:startDelay="1000" p:cronExpression="0 0 0 ? * SAT *" />

• 토요일 00:00에 배치가 시작되며, 작업 시간은 평균 1일

• 배치가 길어지면 새벽 4~5시에도 여전히 실행/트랜잭션 유지가 됨

  → “토요일 새벽에만 락이 보이는 현상”과 시간대가 일치

03. 증상

• image에 대해 삭제/갱신 등 쓰기 쿼리 작업이 락 대기 상태로 누적
• 블로커 트랜잭션 1개가 다수 트랜잭션을 막고 있는 구조로 예상

04. 확인 절차 (어떻게 확인했나)

4.1 Lock wait 존재 확인 (대기/블로커 관계)