저는 매일 50만건이 등록되고 그 자료들이 최소 5회 upate되는 system을 pgsql로 만들어서 운영하고 있습니다. 오늘 backup된 파일의 크기가 gzip으로 압축해서 약 1G네요. 운영한지 한달 좀 넘었습니다. 그리고 DB가 바쁘지 않은 시간을 스케쥴링 할 수가 없습니다. 어떨 때에는 낮 시간이 바쁘고 어떨 때에는 새벽시간이 바쁘고...

이 시스템을 얼마전에 auto vacuum으로 관리하게 바꾸었습니다. 수시로 들어가서 pg_stat_activity를 확인하면 늘 vacuum이 실행되고 있더군요. 일단 vacuum이 되고 있기는 한 것 같습니다. 수동으로 할 때에도 보면 table이 하도 커서 그런지 엄청 오래 걸리더군요.

일단은 auto vacuum을 쓰는 것이 도움이 되는 것 같습니다. 전체 db를 vacuum하지 않고 통계에서 변화가 많이 일어난 table만 골라서 필요할 때 마다 vacuum을 자동으로 하니 이 면에서는 효과적인 것 같아요.

다만 밑에 글을 쓴 것 처럼 DB가 한참 바쁘게 돌아가 IO wait가 20, 30%까지 늘고 있는데 멍청하게 vacuum 작업이 작동되버리면 대략 낭패가... 그래서 저는 vacuum이 더 느리게 작동하되 시스템에 부하를 적게 주는 방식으로 처리를 합니다.

그리고 auto vacuum 때문에 손해를 보는 것은 전체적으로 약간 DB 성능이 떨어진다는 것인데요. 그건 통계를 활성화시켜야 하기 때문에 발생하는 문제이죠. 제 생각에는 auto vacuum 때문 만이 아닌 관리를 위해서라도 통계는 활성화 시키는 것이 좋습니다. 어떤 테이블과 인덱스가 얼마나 또 어떤 방식으로 사용이 되는지 알 수 있으니까요.

제 생각에 auto vacuum을 쓰되 정기적으로 전체 vacuum을 수동으로 작동시켜주는 것이 좋을 것 같더군요. 혹시 어떤 이유로 특정 table이 vacuum되지 않을 수도 있으니까요.

그리고 auto vacuum을 따로 올려줘야 하기 때문에 가끔 실행 시키는 것을 까 먹기도 하구요. 두 instance 이상을 실행시키기도 했었습니다. 두 인스턴스가 올라가는 것을 차단하는 기능이 있으면 좋겠더군요.

저는 8.1에 내장하는 것에 찬성 하구요. 가능하면 vacuum이 내장되던 않던 아에 필요 없는 상황이 되었으면 좋겠어요. 공간을 허비하게 되는 것까지는 오라클도 어느 정도 생기는 문제라서 참을 수 있는데요. seq scan 속도가 느려지는 것은 좀 심각한 문제라고 생각합니다. pgsql의 트렌젝션 처리 방식 때문에 vacuum이 불가피하기는 하지만 좀 더 지능적인 방법이 있지 않을지 기대를 해봅니다.