오늘도 요즘 계속 진행중인 코끼리... 하이!!!! 이번에는 무한... 로딩.... 😅
connection이 끊어져서 그런줄 알았는데 계속 실행이 되고 있어서 아무래도 이럴 때는..테이블 Lock이지! 먼저 수행중인 SQL을 조회한다.
현재 수행중인 SQL전체 조회
select datname, --데이터베이스 이름
pid, --프로세스id
usename, --사용자이름
application_name, --응용프로그램이름
client_addr, --접속ip
client_port, --접속port
backend_start, --서버 접속시간
query_start, --쿼리 시작 시간
wait_event_type,
state, --state정보(하단 참조)
backend_xmin
query --state=active 인 row에 대해 실행중인쿼리
from pg_stat_activity;
state (상태 정보)
- active : 쿼리 실행중
- idle : 새로운 명령 대기중
- idle in transaction : 트랜잭션은 있지만 현재 실행중인 쿼리 없음
- idle in transaction (aborted) : 트랜잭션은 있고 실행중인 쿼리는 없으나 트랜잭션에 오류가 발생
- fastpath function call : 함수 실행중
- disabled : track_activities 무효
해당 Lock걸린 정보를 더 자세하게 알고 싶다면 아래 쿼리를 실행시키면 된다!
Lock 걸린 테이블 조회 .
SELECT t.relname,
l.locktype,
page,
virtualtransaction,
pid,
mode,
granted
FROM pg_locks l,
pg_stat_all_tables t
WHERE l.relation = t.relid
ORDER BY relation ASC;
해당 쿼리를 조회하면 아래와 같이 Lock걸린 테이블이 나오는데 RowExclusiveLock이 검색되면 해당 테이블에 지연되어 다른 쿼리에도 영향을 미칠 수 있으므로 반드시 잡고 있는 트랜잭션이나 서버 상태 등을 점검하여 Lock을 해제 해 주는 작업이 필요하다.
Lock이후에 동일한 테이블을 쓰는 쿼리들이 전부 Lock이 되고 있어서 해당 쿼리를 빠르게 취소 보자..
근본 원인을 알게 됐으니 해당 쿼리들만 빠르게 취소 시킨다.
해당 작업(Process) Kill
- 해당 Pid만 중지
SELECT pg_cancel_backend([pid]);
- 해당 Pid와 연계된 모든 상위 쿼리 프로세스 종료
SELECT pg_terminate_backend([pid]) FROM pg_stat_activity;
우선 pg_cancel_bakend로 작업이 종료 되는지 체크한 후 pg_teminate_backed로 종료하는게 좋은데,
나는 종료할 프로세스가 너무 많아서 pg_teminate_backed로 작업을 종료를 했다.
