Debian Linuxで動作するPostgreSQL 9.1を使用していくつかのベンチマーク作業を行っています。私は、共通の部分を共有するクエリの作業負荷をベンチマークしたいと思います。各クエリを実行する前に、私は、データベースを再起動し、次のコマンドを実行します。PostgreSQL 9.1でのベンチマークのためのキャッシュのフラッシュ
は3>/proc/sys/vm/drop_cachesと
は、共有メモリとOSのキャッシュの両方をドロップを狙っエコー。しかし、別の順序で同じクエリワークロードを実行すると、異なるクエリ応答時間が発生することに気付きました。どういうわけか、クエリオプティマイザは、一般的なクエリ部分を効率的に実行する方法や、以前にキャッシュされた結果を再利用することを覚えていると思います。
この問題を回避する方法はありますか？クエリの順序に関係なく、ほぼ同じ応答時間を得たいと思います。実際の実行時間を抽出するために、EXPLAIN出力を解析していることに注意してください。
最初に気になるのは、自動バキューム（PostgreSQLのバックグラウンドメンテナンスタスク：http://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#AUTOVACUUM）が、予測困難な方法でキャッシュを再投入する作業を行っている可能性があることです。これを無効にすることができますが、これにより膨大な統計情報、統計の悪いプランの選択、フロントエンドプロセスへの追加作業が発生する可能性があることに注意してください。これにアプローチするもう1つの方法は、データをロードした後、VACUUM FREEZE ANALYZEを実行し、すべてを適切な状態にし、PostgreSQLを停止し、OSキャッシュをフラッシュしてから、ベンチマークを実行することです。
問題の原因としては、チェックポイントが考えられます。頻繁なチェックポイントを強制しないようにcheckpoint_segmentsが十分に高く設定されていることを確認する必要があります。また、ベンチマーク中にチェックポイントが発生するタイミングについてcheckpoint_timeout設定を考慮する必要があります。
RAIDコントローラカードまたはハードドライブが十分にキャッシュされている可能性もあります。OSキャッシュをフラッシュするとクリアされるかどうかわかりませんが、疑問です。
一般的に、PostgreSQLには、小さなノートパソコンでデータベースを起動して機能させるための設定が含まれています。最適なパフォーマンスには一般的にチューニングが必要です。ベンチマークで異なる設定をテストしない限り、ベンチマークの前に全体的な構成を見直したいかもしれません。