http://database.sarang.net/?inc=read&aid=9223&criteria=pgsql&subcrit=columns&id=&limit=20&keyword=&page=1

여기서 자세히 설명하고 있습니다.

xlog full에 의한 checkpoint는 작업은 대량 DML 작업이 아주 오래 지속되는 경우에나 발생해야지,

상시 그렇게 발생한다면, wal 쪼가리 파일 갯수를 많이 늘려 주세요.

checkpoint_segments 값을 넉넉하게 늘려주면 됩니다.

checkpoint_completion_target 값을 0.5 보다는 크게 잡아주시고, (0.8 정도가 적당하지 않을까싶네요. )

또 설정할 만한게, bgwriter_delay 값을 줄여서 좀 더 자주 하도록 하고, 

어떻게든 xlog full에 의한 checkpoint 줄일 수 있는 환경을 만드시면 될 것 같네요.

xlog 쪽에 여유가 있어야 트랜잭션이 커밋됩니다. 이게 안되는 세션들이 몰리고, 그 때문에, cpu 사용률이 올라가는 것으로 판단됩니다.

하나 의심스러운 것은 일반적으로 그렇게 xlog 비우는 작업 때문에 발생하는 checkpoint는 16MB 정도가 기록되기 때문에, 1분씩 걸려야 이유가 없거든요. commit 한번에 반영되는  row수가 너무 많은게 아닐까? 하는 생각도 듭니다.

응용프로그램 쪽에서 트랜잭션 관련을 한 번 살펴보아 commit 한번에 반영되는 row수가 너무 많으면 트랜잭션을 쪼갤 수는 없는지도 고민해 보아야 할 것 같습니다.

 음 checkpoint_segments 를 128 로 잡았을 때 하루에 한 번 정도씩 xlog checkpoint 작업이 수행되면서 2분 정도 먹통이 되었었구요, 그래서 너무 크게 잡은게 아닌가 싶어서 최근에 64로 낮추었더니 서너번의 xlog checkpoint 작업이 연속적으로 수행되는 현상이 일어나고 있습니다. 마찬가지로 행이 발생하구요. (재미있게도 이 작업은 하루에 한 순간에 일어납니다.)

여전히 작은 값인 것인가요?

조금 더 자세한 환경을 설명드리자면,

wal_buffer 는 -1 로 되어 있어서 shared_buffer 랑 공유하는 상황이구요,
checkpoint_segments 는 128 -> 64 각가 설정했었습니다.(두 가지 케이스 모두 행을 일으켰습니다.)
checkpoint_completion_target 은 0.5, timeout 은 300초입니다.(default 설정입니다.)

가장 큰 테이블은 약 4천만 건의 데이터를 담고 있으며 전체 데이터베이스 사이즈는 35기가바이트 정도 됩니다.

그리고 기본적으로 복잡한 쿼리가 전혀 없으며 한 번에 여러 건의 insert/update/delete 가 일어나는 트랜잭션은 존재하지 않습니다. 한 번에 한 row 만 insert/update/delete 가 일어나는 구조입니다. 다만 그 빈도수가 엄청 잦긴 합니다.

PS. 해당 글을 이번 장애 때 읽어보고 큰 도움이 되었습니다. 다만 xlog 에 대한 설명이 잘 이해가 안되더라구요 ㅠㅠ 감사합니다.