윈도우 2012 / pgsql 9.5
몇달동안 문제 없더니, 오늘 아침에 발생했네요..
2016-08-09 10:48:56 KST WARNING: worker took too long to start; canceled
이런 오류가 새벽에 몇건 있더니, 점점 빈도수가 늘어나더니, pgadmin 에서도 아예 접속이 안될정도가 되네요..
위 에러메시지외 일반적인 쿼리 로그밖에는 없는데요..
주로 어떤 이유 때문에 발생하는걸까요?..
autovacuum 관리 프로세스가 worker 프로세스를 실행하려고 했는데,
이 worker 프로세스가 정상적으로 시작되지 못해서 발생한 경고입니다.
일반적으로 데이터베이스 서버가 너무 바쁘면 발생하는 경우인데,
pg_stat_activity 뷰를 모니터링 해서, 세션들이 얼마나 바쁘게 움직이지는지 확인이 필요해 보입니다.
OS 시스템 모니터링도 함께 보셔야 할 것 같네요.
거의 쿼리 접속이 없고, DB 용량도 5M 남짓입니다.. (폴더전체는 12M정도)
지금도 낮에도 세션이라고 해봐야 2~3개 밖에 안되거든요.
사용자 쿼리도 1시간에 100건 이내입니다.
해당 현상이 있을때, 사용자 쿼리(select 밖에 없음)를 요청하면 저런 메시지가 쭈욱 로깅됩니다..
버큠을 그렇게 자주할정도는 아닙니다. (데이터 증가나 변경이 거의 없습니다)
영문 글 읽어보면 몇년전글에는 버그라고 되어 있던데요.. 최근 글에는 그런 내용이 없는것 보면, 이미 fix가 되서 거의 발생하지 않는것일테구요..
위 메시지가 발생할만한 다른 이유는 없을까요?..
코드 상, 저 경고는 autovacuum 관리 프로세스가 관리하는 하위 worker 프로세스 가운데 작업을 시작하려고 프로세스 포크를 시도하는 worker의 포인터 값이 null 이 아닌 경우 정리하는 경고입니다.
통상 worker 프로세스는 av_startingWorker -> av_runningWorkers 큐에 넣고 -> av_freeWorkers 큐에 넣고 이렇게 움직이는데, 실행상태로 못빠지는 worker가 있다고 판단하면, 그놈을 리셋해 버립니다. (naptime 동안에도 상태 변화를 못했다면)
원인은 여러가지겠지만, 제일 쉽게 유추하는 것은 해당 OS가 너무 바빠서 60초 동안에도 worker fork 를 못한 경우 일터인데, 그게 아닌게 확실하다면, 다른 원인을 찾아보아야지요.
일단 postgresql.conf 환경 설정파일에서
log_autovacuum_min_duration = 0
이렇게 설정해서 모든 autovacuum 관련 로그를 쌓아서 원인이 될만한 실마리를 찾아보아야 할 것 같습니다.
OS의 postgresql 실행하는 사용자의 최대 프로세스 생성 수 제한 같은게 있는게 아닐까 하는 의심도 듭니다.
여튼 OS쪽 시스템 분석도 필요해 보이기는 합니다.
log_autovacuum_min_duration = 0 이거 해서 로그 함 보도록 해보겠습니다.
감사합니다.