Quiz: Reading a Live Database

막힌 세션의 pg_blocking_pids 가 가리키는 pid 를 끊었는데 상황이 그대로다. 가장 그럴듯한 이유는?

• 끊은 pid 도 자기가 막혀 있던 세션이라 사슬의 끝이 따로 있다
• pg_terminate_backend 는 잠금을 즉시 놓아 주지 않는다
• 잠금이 행이 아니라 표 전체에 걸려 있어 재시작이 필요하다
• 통계 수집기가 갱신되기 전이라 옛 값을 보고 있다

요청이 응답하지 않는데 느린 쿼리 목록이 비어 있다. 가장 먼저 볼 것은?

• 지난 한 시간의 평균 응답 시간 추이 그래프
• 체크포인트 주기와 WAL 생성량
• 가장 오래된 트랜잭션의 나이와 idle in transaction 세션
• 공유 버퍼 적중률과 디스크 읽기 대기

한 세션의 wait_event 가 transactionid, 다른 세션은 tuple 이다. 이 차이가 뜻하는 것은?

• 앞은 행 잠금이고 뒤는 표 잠금이라 잠금의 범위가 다르다
• 앞은 잠금을 쥔 트랜잭션을 직접, 뒤는 같은 행 대기 줄의 앞사람을 기다린다
• 앞은 읽기 잠금이고 뒤는 쓰기 잠금이라 충돌 조건이 다르다
• 앞은 교착 검사 전이고 뒤는 교착 검사를 이미 통과한 상태다

lock_timeout 이 0(기본값)인 서비스에서 한 행에 요청이 몰릴 때 가장 먼저 바닥나는 것은?

• 데이터베이스 서버의 CPU
• 공유 버퍼와 작업 메모리
• WAL 을 쌓아 두는 디스크 공간
• 애플리케이션의 커넥션 풀

커넥션이 꽉 찼을 때 max_connections 를 올리는 것이 첫 수가 아닌 이유는?

• 모자란 게 아니라 반납이 안 되는 것이라 묶이는 커넥션의 상한만 올라간다
• 이 설정은 재시작해야 반영되므로 장애 중에 바꿀 수 없다
• 슈퍼유저용 예비 슬롯이 함께 줄어 관리 접속이 막힌다
• 커넥션 수가 늘면 잠금 대기가 교착으로 바뀌기 때문이다

마이그레이션에 lock_timeout 을 반드시 거는 이유는?

• DDL 은 롤백할 수 없어서 중간에 끊을 방법이 그것뿐이라서
• 잠금을 오래 쥐면 WAL 이 재활용되지 않아 디스크가 차기 때문
• ACCESS EXCLUSIVE 대기가 그 뒤의 읽기까지 전부 줄 세우기 때문
• 대기 중인 DDL 이 교착으로 감지되지 않아 영원히 남기 때문