Postgres DISK IO가 매우 높습니다. 즉시 줄이려면 어떻게해야합니까?

사용중인 것보다 빠른 디스크가 도움이된다는 것을 알고 있지만 넣는 데 시간이 오래 걸리고 응급 조치를 사용하여 디스크 IO를 줄이려고합니다. 꼭대기에서 거의 빨간색으로 DSK 사용량을보고하고 있습니다. 이것은 postgres 8.3 용입니다.

서버에 16GB의 램이 있지만 완전히 사용되지는 않지만 나의 shared_buffers 설정은 24MB입니다. 내 첫 번째 생각은 데이터베이스에 가능한 한 많은 양의 램을 제공하는 것이었지만 어떻게 해야할지 모르겠습니다 (이것은 전용 데이터베이스 서버입니다).

재시작이 필요없는 솔루션이 바람직하지만이 시점에서 얻을 수있는 것을 취할 것입니다.

감사!

24MB shared_buffers 설정은 보수적 인 기본값이므로 16GB의 RAM을 사용할 수있는 전용 데이터베이스의 경우 훨씬 높아야한다고 말하고 싶습니다. 그러나 예, 서버 크기를 조정하려면 서버를 다시 시작해야합니다. http://wiki.postgresql.org/wiki/Performance_Optimization 은 성능 구성 지침을 시작하기에 좋은 장소입니다. shared_buffers를 4GB 또는 6GB로 설정하는 것이 더 합리적입니다.

리눅스에서는이 공유 메모리의 블록을 할당하기 위해 kernel.shmmax sysctl 설정 (/etc/sysctl.conf에서 또는 / proc / sys / kernel / shmmax를 작성하여)을 조정해야합니다. 요청 된 양을 지정하는 동안 오류가 발생하지 않으면 kernel.shmmax를 그보다 높게 설정해야합니다.

메모리가 많으므로 기본 work_mem을 높게 설정하면 정렬 및 해시 (그룹 / 순서 / 고유 등)가 임시 파일을 사용하지 않고 메모리에서 작동하는 경향이 있습니다. 이를 위해 서버를 다시 시작할 필요는 없습니다. 설정 파일을 업데이트하고 서비스를 다시로드하면 새 세션에 새로운 설정이 적용됩니다. 세션의 기본 작업 메모리는 1MB이며, 한 번에 사용될 수있는 최대 값을 계산하고 work_mem * max_client_connections어떤 영향을 미칠지 추정 할 수 있습니다.

또한 커널 FS 계층이 postgresql의 공유 버퍼 외부의 메모리에서 많은 페이지를 캐싱 할 가능성이 있음을 플래너에게 표시하려면 effective_cache_size를 늘려야합니다.

등을 시작하면 좋은 출발을 할 수 있기를 바랍니다.

와 디스크 다시 마운트 하는 noatime을

여기에 제시된 제안 외에도 자동 진공 설정을 살펴볼 수도 있습니다. 기본적으로 약 50 번의 업데이트 후에 트리거되며 데이터베이스에서 많은 업데이트 / 삽입을 수행하면 불필요한 양의 진공 문을 트리거하여 많은 IO를 생성 할 수 있습니다.

정상 작동 중 최대 I / O 처리량에 매우 가까운 시스템에서 checkpoint_completion_target을 증가시켜 검사 점의 I / O로드를 줄일 수 있습니다. 단점은 복구에 사용하기 위해 더 많은 WAL 세그먼트를 유지해야하기 때문에 검사 ​​점을 연장하면 복구 시간에 영향을 미친다는 것입니다

자세한 내용은 여기를 참조 하십시오 .

postgresql의 diskio가 매우 높은 경우, 특히 "디스크 정렬"을 수행하는 명령문에 대해 실행중인 명령문을 점검하고 적절한 색인을 설정해야합니다.

"Postgresql Performance Tuning"에 대한 Google 만 있으면 시작 위치가 충분합니다.