たとえば、パフォーマンス考古学の話（PostgreSQL 7.4から9.4までの評価）など、さまざまなPostgreSQLバージョンを比較する複数のベンチマークを公開しました。これらのベンチマークはすべて、固定環境（ハードウェア、カーネルなど）を想定しています。これは多くの場合（パッチのパフォーマンスへの影響を評価する場合など）は問題ありませんが、本番環境では時間の経過とともに変化します。ハードウェアのアップグレードを取得し、新しいカーネルバージョンのアップデートを取得することがあります。
ハードウェアのアップグレード（より良いストレージ、より多くのRAM、より高速なCPUなど）の場合、影響は通常かなり簡単に予測できます。さらに、人々は一般に、生産のボトルネックを分析し、おそらく最初に新しいハードウェアをテストすることによって影響を評価する必要があることを認識しています。 。
しかし、カーネルの更新についてはどうでしょうか？残念ながら、私たちは通常、この分野で多くのベンチマークを行いません。ほとんどの場合、新しいカーネルは古いカーネルよりも優れています（より高速で、より効率的で、より多くのCPUコアに拡張できます）。しかし、それは本当に本当ですか？そして、その違いはどのくらいですか？たとえば、カーネルを3.0から4.7にアップグレードするとどうなりますか？それはパフォーマンスに影響しますか？そうであれば、パフォーマンスは向上しますか？
時々、特定のカーネルバージョンでの深刻なリグレッション、またはカーネルバージョン間の突然の改善に関するレポートを受け取ります。明らかに、カーネルバージョンはパフォーマンスに影響を与える可能性があります。
3.0〜3.8カーネルを回避するための推奨事項に応えて、2014年にSergey Konoplevによって作成された、さまざまなカーネルバージョンを比較する単一のPostgreSQLベンチマークを知っています。しかし、そのベンチマークはかなり古いので（18か月前に利用可能な最後のカーネルバージョンは3.13でしたが、現在は3.19と4.6です）、現在のカーネル（およびPostgreSQL 9.6beta1）でいくつかのベンチマークを実行することにしました。
>PostgreSQLとカーネルのバージョン
ただし、最初に、2つのプロジェクトのコミットを管理するポリシー間のいくつかの重要な違いについて説明します。 PostgreSQLには、メジャーバージョンとマイナーバージョンの概念があります。メジャーバージョン（9.5など）は、およそ1年に1回リリースされ、さまざまな新機能が含まれています。マイナーバージョン（9.5.2など）にはバグ修正のみが含まれ、約3か月ごとに（または、より頻繁に、重大なバグが発見された場合に）リリースされます。したがって、マイナーバージョン間でパフォーマンスや動作に大きな変化はないはずです。これにより、広範なテストを行わなくてもマイナーバージョンを展開するのはかなり安全になります。
カーネルバージョンでは、状況ははるかに明確ではありません。 Linuxカーネルにもブランチ（2.6、3.0、4.7など）があります。これらは、バグ修正だけでなく新機能を引き続き受けているため、PostgreSQLの「メジャーバージョン」とは決して異なりません。 PostgreSQLのバージョニングポリシーが何らかの形で自動的に優れているとは言いませんが、その結果、マイナーカーネルバージョン間での更新は、パフォーマンスに大きな影響を与えたり、バグを引き起こしたりする可能性があります（たとえば、3.18.37は、このような非バグ修正のためにOOMの問題に悩まされます）コミット）。
もちろん、ディストリビューションはこれらのリスクを認識しており、多くの場合、カーネルバージョンをロックし、新しいバグを取り除くためにさらにテストを行います。ただし、この投稿では、www.kernel.orgで入手できるバニラの長期カーネルを使用しています。
ベンチマーク
使用する可能性のあるベンチマークは多数あります。この投稿では、一連のpgbenchテスト、つまり、かなり単純なOLTP（TPC-Bのような）ベンチマークを紹介します。他のベンチマークタイプ（特にDWH / DSS指向）で追加のテストを行う予定です。将来、このブログでそれらを紹介します。
さて、pgbenchに戻りましょう。「テストのコレクション」と言うときは、の組み合わせを意味します
- 読み取り専用と読み取り/書き込み
- データセットのサイズ–アクティブセットは共有バッファ/ RAMに適合しません（適合しません）
- クライアント数–単一のクライアントと多数のクライアント（ロック/スケジューリング）
値は明らかに使用されているハードウェアに依存するため、このラウンドのベンチマークが実行されていたハードウェアを見てみましょう。
- CPU：Intel i5-2500k @ 3.3 GHz（3.7 GHzターボ）
- RAM：8GB（DDR3 @ 1333 MHz）
- ストレージ：RAID-10（Linux SW RAID）の6x Intel SSD DC S3700
- ファイルシステム：デフォルトのI / Oスケジューラー（cfq）を備えたext4
つまり、これまでの多くのベンチマークで使用したマシンと同じです。かなり小さいマシンであり、最新のCPUなどではありませんが、それでも妥当な「小さい」システムだと思います。
ベンチマークパラメータは次のとおりです。
- データセットのスケール：30、300、1500（つまり、約450 MB、4.5 GB、22.5 GB）
- クライアント数：1、4、16（マシンには4つのコアがあります）
組み合わせごとに、3回の読み取り専用実行（各15分）と3回の読み取り/書き込み実行（各30分）がありました。ベンチマークを推進する実際のスクリプトは、（結果やその他の有用なデータとともに）ここから入手できます。
注 ：ハードウェアが大幅に異なる場合（回転ドライブなど）、結果が大きく異なる場合があります。テストしたいシステムがある場合は、お知らせください。サポートさせていただきます（結果の公開が許可されていると仮定します）。
カーネルバージョン
カーネルバージョンに関しては、2.6.x以降のすべての長期ブランチ（2.6.39、3.0.101、3.2.81、3.4.112、3.10.102、3.12.61、3.14.73、3.16）で最新バージョンをテストしました。 36、3.18.38、4.1.29、4.4.16、4.6.5および4.7）。 2.6.xカーネルで実行されているシステムはまだたくさんあるので、新しいカーネルにアップグレードすることでどれだけのパフォーマンスが得られる（または失われる）かを知ることは有用です。しかし、私はすべてのカーネルを自分でコンパイルしており（つまり、バニラカーネルを使用し、ディストリビューション固有のパッチは使用していません）、構成ファイルはgitリポジトリにあります。
結果
いつものように、
を含むすべてのデータはbitbucketで利用できます- kernel.configファイル
- ベンチマークスクリプト（run-pgbench.sh）
- PostgreSQL構成（ハードウェアの基本的な調整を含む）
- PostgreSQLログ
- さまざまなシステムログ（dmesg、sysctl、mount、…）
次のグラフは、ベンチマークされた各ケースの平均tpsを示しています。3回の実行の結果はかなり一貫しており、ほとんどの場合、最小値と最大値の差は最大2％です。
読み取り専用
最小のデータセットの場合、すべてのクライアント数で3.4から3.10の間に明らかにパフォーマンスが低下します。ただし、16クライアント（コア数の4倍）の結果は、3.12で回復する以上のものです。
中程度のデータセット（RAMには収まるが、共有バッファには収まらない）の場合、3.4と3.10の間で同じ低下が見られますが、3.12での回復は見られません。
大規模なデータセット（RAMを超えるため、I / Oバウンドが非常に大きい）の場合、結果は大きく異なります。3.10と3.12の間で何が起こったかはわかりませんが、パフォーマンスの向上（特にクライアント数が多い場合）は非常に驚くべきものです。
読み取り/書き込み
読み取り/書き込みワークロードの場合、結果はかなり似ています。中小規模のデータセットでは、3.4と3.10の間で同じ約10％の低下が見られますが、残念ながら3.12では回復しません。
大規模なデータセット（ここでも、大幅にI / Oバウンド）の場合、3.12でも同様の改善が見られます（読み取り専用ワークロードほど重要ではありませんが、それでも重要です）：
概要
単一のマシン上の単一のベンチマークから結論を引き出すことはあえてしませんが、次のように言っても安全だと思います。
- 全体的なパフォーマンスはかなり安定していますが、パフォーマンスに大幅な変化が見られます（両方向）。
- メモリ（shared_buffersまたは少なくともRAMのいずれかに）に収まるデータセットでは、3.4から3.10の間で測定可能なパフォーマンスの低下が見られます。読み取り専用テストでは、これは3.12で部分的に回復します（ただし、多くのクライアントの場合のみ）。
- データセットがメモリを超えているため、主にI / Oバウンドであるため、このようなパフォーマンスの低下は見られませんが、3.12では大幅な改善が見られます。
これらの突然の変化が起こる理由については、よくわかりません。バージョン間には関連する可能性のあるコミットが多数ありますが、大規模な（そして時間のかかる）テストを行わずに正しいコミットを特定する方法がわかりません。他にアイデアがある場合（たとえば、そのようなコミットを知っている場合）、私に知らせてください。