先月の低PostgreSQLレイテンシー向けのTuningLinuxのフォローアップとして、2つのファイルシステム、3つのパッチ、および2セットのカーネルチューニングパラメーターで実行される膨大な数のテストが行われています。これまでの結果は、いくつかの興味深い新しいデータであり、現在PostgreSQL 9.1にあるこの領域でのもう1つのコミットされた改善です（合計3つ、他の2つは監視パッチです）。来月のPostgreSQLEastでの講演の中で、推奨されるプラクティスについて話します。この分野で5月のPGConにも何かを提出しました。ここでは、行き止まりについてもう少し話しますが、それらの思い出はまだ新鮮です。
ここでの基本的な問題は、PostgreSQLが書き込み時にオペレーティングシステムのキャッシュを使用する方法により、大量のデータが蓄積されることです。データベースチェックポイントが終了したときの結果は、そのデータが書き込まれるのを待っている間、長い遅延になる可能性があります。 PostgreSQLに付属しているpgbenchプログラムは、この問題の作成に非常に優れていることがわかったので、それをすべてのテストに使用しました。私が答えようとした手段の質問は次のとおりです。
- 古いext3ファイルシステムから変更すると、データベースタスクのパフォーマンスが本当に向上しますか？私は昨年、LinuxでのXFSの復活について何かを書きましたが、それは単純なベンチマークで素晴らしい改善を示しました。ただし、それが必ずしもデータベースの改善につながるとは限りません。
- 最近のLinuxのdirty_bytesとdirty_background_bytesの調整機能は、ワーストケースのレイテンシーを本当に改善しますか？
- ここでの動作を改善するために提案されたデータベースの変更のうち、実際に機能するのはどれですか？
生データを確認したい場合は、すべてのテスト結果を確認できます。各テストセットで変更された内容が文書化されており、個々のテストにドリルダウンすると、使用されているデータベースパラメータやその他の基本的なOS情報を確認できます。この種のことを自分で試してみたい場合は、そのWebページが私のpgbench-toolsテストプログラムから得られるものです。
結果はそれほど驚くべきものではありませんでしたが、興味深いものでした。ここでのすべてのテストは、2つのデータベースサイズで実行されました。より小さなデータベースサイズ（スケール=500、サーバーの16GBのRAMに簡単に収まる約8GBのデータベース）では、ext3は690トランザクション/秒を管理しましたが、その2倍のサイズ（スケール=1000、約16GBのデータベース）では、それははるかに大きかったより多くのシークバウンドと349TPSのみを管理しました。 XFSは、これら2つの数値を1757TPSと417TPSに増やしました。それぞれ255％と19％の増加です。さらに良いことに、単一トランザクションのワーストケースのレイテンシーは、34〜56秒の範囲（！）から2〜5秒の範囲に低下しました。 5秒でも素晴らしいことではありませんが、これはこの問題を非常に悪化させるように設計された合成ワークロードです。 ext3の数値は非常にひどいので、以前のカーネルで見たよりもそのファイルシステムで実際に良い動作が見られたとしても、ここで厄介な問題が発生する可能性があります（これは2.6.32で行われました）。
ラウンド1：XFSが地滑りで勝ちました。大量の書き込みを計画している場合、大量のメモリを備えたLinuxシステムで実行可能なファイルシステムとしてext3を推奨することはできません。そのコンテキストでは機能しません。このサーバーには16GBのRAMしか搭載されていなかったため、2011年の深刻な運用サーバーでこの問題がどれほど深刻であるかを想像できます。
次に、dirty_bytesとdirty_background_bytesの調整可能ファイル。これらの2つは、いくつかの速度低下を犠牲にして、ext3でかなりのレイテンシーを改善しました。最悪の場合、VACUUMを実行するとメンテナンス時間が遅くなり、テスト結果自体には表示されません。これについては、以前のブログエントリですでに説明しました。 XFSでは、これらのパラメーターを調整することはパフォーマンスの低下につながります。データベースの規模が小さい場合、TPSのパフォーマンスは46％低下し、それに加えてレイテンシーは実際に悪化します。
ラウンド2：dirty_bytesまたはdirty_background_bytesからの奇跡を期待しないでください。状況によっては、何らかのプラスの効果があるように見えますが、潜在的なマイナス面も大きいです。これら2つを下方に調整する前に、慎重にテストし、テストにVACUUMを含めるようにしてください。
次に、この最後のCommitFestの一部としてPostgreSQLに対する3つのパッチのアイデアを評価することになりました：
- チェックポイントのディスクへの同期（fsync）の呼び出しを時間の経過とともに広げます。他の同期操作がデータベースによってキャッシュされる方法の処理が改善された場合、ビジー状態のクライアントサーバーである程度の成功が見られました。
- コンパクトなfsyncリクエスト。このアイデアは最初のアイデアから生まれ変わり、RobertHaasによって書かれたパッチになりました。アイデアは、データをディスクに同期しようとしているクライアントがチェックポイントの書き込みと競合している可能性があるということです。このパッチの機能は、クライアントがfsyncリクエストのキューがいっぱいになった場合に、キューをクリーンアップできるようにすることです。
- ソートチェックポイントの書き込み。概念は、データベースが物事がディスクに保存されていると信じる順序で物事を書き出す場合、OSがより効率的に書き出す可能性があるということです。このパッチは数年前に表示され、いくつかのベンチマーク結果はそれが機能したことを示唆していますが、当時は誰も改善を再現できませんでした。このアイデアは残りの作業に十分に適合しているので、もう一度評価しました。
ラウンド3：これを何週間も試した後、ほぼすべてのワークロードサイズで改善が見られたこのセットの唯一のアプローチは、fsync圧縮のアプローチでした。元のスプレッドチェックポイント同期コードはこの領域で一部役立ちましたが、現在9.1用にコミットされている特定の実装はさらにうまく機能しました。私が実行したほとんどの書き込みの多いテストでは、ほぼ全面的に10％の増加でした。これはPostgreSQL9.1の大幅な改善であり、ここでの本番システムの速度低下の原因となる問題を完全に排除する必要があります。
ここにある残りのアイデアは、重い後、それほど肯定的な評価を得られませんでした。ベンチマークなので、今のところそれらは棚に戻ります。ここで引き続きデータを収集します（いくつかのext4テストは次に試すべき論理的なことです）。その後、再び開発に戻ります。いくつかの難しいワークロードで10％のゲインを得るのは確かに素晴らしいことですが、チェックポイントの同期の問題をクローズドサブジェクトと見なすには、最悪の場合の動作がまだ多すぎます。