쓰기 성능을위한 PostgreSQL 구성

내 PostgreSQL 서버 중 하나가 일정한 데이터 스트림을 수신하는 여러 (1-3) 데이터베이스를 호스팅합니다. 데이터는 특별히 구조화되어 있지 않으며, 현재 시간과 특정 순간에 대한 다양한 관측 데이터에 해당합니다. 데이터 속도는 상당히 높습니다. 한 데이터베이스의 경우 하루에 약 기가 바이트, 다른 데이터베이스의 경우 약 10 분의 1이됩니다. 나는이 비율이 증가 할 것으로 기대하지 않습니다. 읽기 성능은 우선 순위가 훨씬 낮으며 현재 허용됩니다.

로그에 다음 메시지가 있습니다.

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

이 값은 현재 16으로 설정되어 pgtune있습니다.

쓰기 성능을 향상시키기 위해 고려해야 할 설정은 무엇입니까? 가능한 한 많은 안전을 유지하고 싶습니다. 들어오는 데이터의 양을 고려할 때 대량의 데이터가 손상되지 않는 한 최근의 일부 데이터가 손실 될 수 있습니다.

편집 : 지금은 PostgreSQL 9.0을 사용하고 있지만 9.1로 업그레이드 할 계획입니다. 하드웨어의 세부 사항을 게시하지는 않습니다. 하드웨어의 중요성을 인정하는 동안 궁극적으로 매우 다양한 하드웨어가있는 여러 컴퓨터에서이 최적화를 수행해야합니다. 하드웨어가 응답에 필수적인 경우, 하드웨어 구성이 다른 시스템에 응답을 적용 할 수 있도록 일반 정보를 알려주십시오.

1 기가 바이트는 쓰기로드가 그리 높지 않습니다. 하루 종일 퍼져서 초당 약 50kbyte로 나옵니다. 느린 USB 썸 드라이브가이를 처리 할 수 ​​있습니다. 그래도 더 폭발적이라고 가정합니다. a_horse_with_no_name에서 알 수 있듯이 검사 점 세그먼트를 늘리십시오. 100 정도는 평범하지 않습니다.

그런 다음 checkpoint_timeout1 시간으로 늘리고 checkpoint_completion_target1.0 (100 %)에 가까운 것을 늘리십시오 . 완료 대상은 체크 포인트를 실행하기 전에 x % 완료되도록 백그라운드에서 PostgreSQL에 얼마나 적극적으로 글을 쓰는지 알려주므로 WAL에서 모든 데이터가 한 번에 작성되고 시스템이 크롤링되는 속도가 느려집니다.

일반적으로 100 %로 설정하지 않는 이유는 동일한 블록에 두 번 이상 쓰는 것이 일반적이기 때문에 WAL 쓰기를 주 저장소에 지연시켜 동일한 블록이 이유없이 두 번 쓰지 않도록하는 것입니다.

시간 초과가 발생하기 전에 같은 블록에 두 번 이상 쓰지 않을 것입니다. 즉, 삽입 한 다음 꽤 높게 설정하면 0.9 정도로 올리는 것이 좋습니다. 최악의 상황은 필요할 때보 다 조금 더 자주 쓰는 것이지만 체크 포인트 영향은 크게 줄어 듭니다.

'무거운 쓰기'시스템에서는 피크 활동 중에 WAL을 작성할 수있는 속도로 제한을받을 수 있습니다.

"실패한 최근 데이터 손실을 수용 할 수있는"경우 동기 커밋 을 해제 할 수 있습니다 .

트랜잭션의 내구성에 대한 정확한 확실성보다 성능이 더 중요한 경우 유용한 대안이 될 수 있습니다.

하드웨어를 변경할 수 있으면 쓰기 최적화를 위해 다음 중 하나를 고려할 수 있습니다.

• RAID5를 통한 RAID10
• 많은 스핀들 (예 : 3.5 "대신 2.5"를 의미 할 수 있음)
• SATA over SAS
• 10K 드라이브에서 15K
• SSD

--편집하다

@Scott 의 탁월한 답변 에 대한 귀하의 의견 : "쓰기 볼륨이 실제로 거의 균일합니다"및 암시 적 데이터 속도 "초당 50kbyte"에 따르면 데이터 손실 위험이있는 모든 작업을 수행해야한다고 의심합니다. 아마도 다른 구성 매개 변수 중 어떤 것이 설정되어 있는지 아는 것이 도움이 될 것입니다.

커밋의 빈도 / 크기를 확인할 수도 있습니다. 최근에 단일 트랜잭션에서 백만 개가 넘는 레코드를 업데이트하려고하는 문제가 발생했습니다. OP에 설명 된 것과 유사한 로그 메시지가 표시되었지만 몇 시간이 지난 후에도 트랜잭션을 완료 할 수 없습니다. 몇 개의 작은 트랜잭션 (10,000 레코드 정도)으로 쓰기 작업을 중단하면 총 소요 시간이 약 15 분으로 줄었습니다.

내가 생각한 것은 Postgres가 checkpoint_timeout 이 로그를 작성하는 데 많은 시간을 소비 하여 레코드를 저장하는 데 상당한 진전을 이뤘다는 것입니다. 그 설명이 잘 맞는지 잘 모르겠습니다. 여전히 경고 메시지가 표시되지만 모든 쓰기 작업이 결국 처리됩니다. 그러나 데이터베이스 재구성이 필요한 프로그래밍 방법이 아니라 프로그래밍 방식이 필요했습니다.

참조 http://www.postgresql.org/docs/9.3/static/wal-configuration.html