Postgres 9.1.3を実行していますが、最近、サーバーの1つで大きなパフォーマンスの問題が発生し始めました。
クエリはしばらくの間正常に実行されましたが、8月1日の時点で、劇的に遅くなっています。問題のあるクエリのほとんどはSelectクエリであるように見えますが（count（*）を使用したクエリは特に悪いです）、一般に、データベースの実行速度は非常に遅くなります。
サーバーでこのクエリを実行しました。これらはデフォルトの構成ファイルに加えた変更です（注：サーバーは以前はこれらの変更で正常に実行されていたため、それほど重要ではない可能性があります）：
name | current_setting
---------------------------+---------------------------------------------------------------------------------------------------------------
version | PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51), 64-bit
autovacuum | off
bgwriter_delay | 20ms
checkpoint_segments | 6
checkpoint_warning | 0
client_encoding | UTF8
default_statistics_target | 1000
effective_cache_size | 4778MB
effective_io_concurrency | 2
fsync | off
full_page_writes | off
lc_collate | en_US.UTF-8
lc_ctype | en_US.UTF-8
listen_addresses | *
maintenance_work_mem | 1GB
max_connections | 100
max_stack_depth | 2MB
port | 5432
random_page_cost | 2
server_encoding | UTF8
shared_buffers | 1792MB
synchronous_commit | off
temp_buffers | 16MB
TimeZone | US/Eastern
wal_buffers | 16MB
wal_level | minimal
wal_writer_delay | 10ms
work_mem | 16MB
(28 rows)
Time: 210.231 ms
通常、このような問題が発生した場合、人々が最初に推奨するのは掃除機をかけることであり、私たちはそれを試みました。ほとんどのデータベースを真空分析しましたが、役に立ちませんでした。
一部のクエリで使用Explainしたところ、テーブルにインデックスが含まれていても、Postgresがシーケンシャルスキャンに頼っていることに気づきました。
シーケンシャルスキャンをオフにして、クエリプランナーにインデックスの使用を強制しましたが、それも役に立ちませんでした。
次に、このクエリを試して、Postgresが探しているものを見つけるために通過していた未使用のディスクスペースがたくさんあるかどうかを確認しました。残念ながら、一部のテーブルには少しかさばりがありましたが、システム全体のパフォーマンスを低下させるほど重要ではないようでした。
減速はI/Oに関連している可能性があると思いますが、詳細を把握することはできません。Postgresはばかげているだけですか？もしそうなら、それのどの部分ですか？VMに何か問題がありますか、それとも物理ハードウェア自体に問題がありますか？
私たちが試したりチェックしたりできることについて、他に何か提案はありますか？
編集：
これを早く更新しなかったことをお詫びします。私は他のことに巻き込まれました。
この特定のマシンでは、仮想マシンの設定に1つの小さな変更を加えることで、パフォーマンスが大幅に向上しました。
IOキャッシングを扱う設定があります。元々はONに設定されていました。常に物事をキャッシュすることは物事を遅くしていると私たちは考えました、そして私たちは正しかったです。オフにしたところ、大幅に改善しました。
興味深いことに、他のほとんどのサーバーではすでにこの設定がオフになっています。
他にも問題がありますが、たくさんのご提案をお待ちしておりますので、よろしくお願いします。