한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

대량 배치 작업 Batch jobs during service

원인 ID db-batch · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

그림과 실험이 있는 원본 카드로 열기 →

랭킹 집계, 우편 일괄 발송, 오래된 데이터 정리를 운영 중에 돌리면 잠금과 디스크를 차지합니다.

왜 운영 시간에 대량 작업 실행 → 그러면 넓은 범위 잠금, 디스크·CPU 점유 → 화면에서는 특정 시간대 거래·저장 실패, 로딩 지연

증상: 입력 지연, 씹힘·롤백
요인: 지연, 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 일정한 주기로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 잘게 나눠 조금씩, 집계는 복제본에서.
인프라팀 할 일: 집계용 복제본 제공, 배치는 한가한 시간대로 예약, 잠금 에스컬레이션·갭 락 대기 감시.
그래프에서는: 일정 주기로 튐 · DB 쿼리 지연, 잠금 대기
확인할 곳: 렉 시각에 돌던 긴 쿼리를 찾음. MySQL은 slow query log, PostgreSQL은 pg_stat_activity의 query_start·query를 보고, 같은 시각의 잠금 대기 지표와 배치 일정(크론, DB 이벤트 스케줄러)을 대조함. SQL Server는 lock_escalation 확장 이벤트로 잠금 에스컬레이션을 기록함
이러면 맞음: 매번 같은 시각 대량 UPDATE·DELETE·집계 쿼리가 돌고 그동안 잠금 대기와 디스크 이용률이 함께 오름
이러면 아님: 그 시각에 긴 쿼리가 없으면 체크포인트(db-checkpoint)나 서버 백업(dk-backup)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: SQL Server는 한 문장이 행 잠금을 약 5,000개 넘게 잡으면 테이블 잠금으로 바꿉니다(잠금 에스컬레이션). 그 순간 같은 테이블을 쓰는 모든 요청이 멈춥니다. MySQL도 기본 설정에서 범위 조건으로 고치면 행 사이 빈틈까지 잠가(갭 락) 새 행 추가를 막습니다.

출처

Transaction Locking and Row Versioning Guide Microsoft SQL Server
한 문장이 한 테이블(또는 인덱스)에서 잠금을 5,000개 이상 잡으면 잠금 에스컬레이션, lock_escalation 확장 이벤트로 기록
InnoDB Locking MySQL
InnoDB 기본 격리 수준 REPEATABLE READ에서는 검색·스캔에 next-key 잠금을 써서, 갭 락이 그 빈틈의 새 행 추가를 막음
The Slow Query Log MySQL
long_query_time을 넘긴 쿼리를 실행 시간(Query_time)·잠금 시간(Lock_time)·읽은 행 수와 함께 기록
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: 세션마다 지금 실행 중인 쿼리(query)와 시작 시각(query_start)

대량 배치 작업 Batch jobs during service

출처

함께 보면 좋은 원인

같은 층: L12 데이터베이스

같은 증상(입력 지연)의 다른 층 원인