私は、PostgreSQLの一部を簡単にテストできるようにすることを目的としたプロジェクトを数多く維持しています。これらはすべて、先週、まともなアップグレードを取得しました。
ストリームスケーリングは、より多くのコアが機能するようになると、サーバーのメモリ速度がどのように向上するかをテストします。それは魅力的なデータであり、実際の傾向を見始めるのに十分なデータです。多くのコアがあるため、CPUキャッシュが大量にあるシステムで正しく機能するようになりました。以前は、キャッシュへの影響を回避するためにテストセットのサイズ設定に積極的になり、現在のストリームコードの設計で割り当てられるよりも多くのメモリを使用する可能性がありました。それは縮小されました。 48コア以上のサーバーを使用している場合は、この新しいコードをさらにテストして、これを処理する新しい方法が理にかなっているかどうかを確認できます。
pegは、ソースからPostgreSQLを簡単に構築できるようにするために作成したスクリプトです。通常、開発者の作業や、本番システムで新しいバージョンを一時的に試すために使用します。以前は、プロジェクトとそれに関連するgitブランチ間の切り替えと混同するのは非常に簡単でした。この分野のドキュメントは大幅に改善されています。
pgbench-toolsは私のパフォーマンステストの救貧院であり、数日分のベンチマークマークをキューに入れて、それを理解するのに十分な分析ツールを利用できるようにします。プログラムは、最近導入されたpg_stat_bgwriter.buffers_backend_fsyncパラメーターを、それをサポートするバージョンがある場合に追跡するようになりました（現在、最近のsourビルドのみ-ペグが役立つ理由に戻ります）。また、各テストを一定時間実行するように指示することもできます。これにより、大きく変化するクライアント/サイズの値でのテストがはるかに簡単になります。
pgbench-toolsでできることに関しては…今日の時点で、私が無制限に使用できる最も強力なサーバーでPostgreSQL9.1で行っているベンチマークテストを共有しています。 8コア、16GB RAM、3ディスクRAID-0データベースドライブ、1ディスクWALボリューム、Arecaバッテリーバックアップキャッシュ。結果を見ることができます。実行はテストセットに編成され、各テストセットは構成に対するある種の変更を表します。たとえば、このデータの＃1はSELECTのみを実行し、＃2はTPC-Bのように実行されていますが、8 GBのRAMとealrierコードを使用していますが、ホットなものは＃3で、16GBのRAMとコードを使用してTPC-Bを実行しています。 buffers_backend_fsyncsを追跡します。
PostgreSQL 9.1キューには、これらの結果によって強調された領域のパフォーマンスに関連するいくつかのパッチがあります。Linuxは、書き込みが多いデータベースのロードで非常に高いワーストケースのレイテンシーを持つ可能性があります。良い平均的な例は、テスト215です。スケールは1000、32クライアント、365 TPSです。ただし、最悪の場合のレイテンシは43秒であり、TPSグラフでデッドスポットを確認できます。それはひどいことであり、それを行う方法についてはいくつかの概念が浮かんでいます。
これを読んでいる人が、このようなテストを実行するために数週間利用できる強力なサーバーを持っている場合は、この環境を複製して、どのような結果が表示されるかを確認できるようにサポートさせていただきます。私が持っている唯一の魔法は、非生産的なテストに多くの時間を費やさないように、スケーリングとクライアントの負荷を設定する方法の練習です。残りのプロセスはすべて無料で文書化されています。