2つの深刻なセキュリティの脆弱性（MeltdownとSpectreという名前のコード）が数週間前に明らかになりました。初期のテストでは、（カーネルに追加された）緩和策のパフォーマンスへの影響は、システムコール率に応じて、一部のワークロードで最大30％になる可能性があることが示唆されました。
これらの初期の見積もりは迅速に行う必要があったため、限られた量のテストに基づいていました。さらに、カーネル内の修正は時間の経過とともに進化および改善され、retpolineも取得されました。 Spectrev2に対応する必要があります。この投稿では、より徹底的なテストからのデータを紹介し、典型的なPostgreSQLワークロードのより信頼性の高い見積もりを提供することを願っています。
サイモンが1月10日に投稿したメルトダウン修正の初期評価と比較すると、この投稿で提示されたデータはより詳細ですが、一般的にはその投稿で提示された結果と一致します。
この投稿はPostgreSQLのワークロードに焦点を当てており、syscall /コンテキストスイッチレートが高い他のシステムには役立つかもしれませんが、どういうわけか普遍的に適用できるわけではありません。脆弱性と影響評価のより一般的な説明に興味がある場合は、BrendanGreggが数日前に優れたKPTI/KAISERメルトダウン初期パフォーマンス回帰の記事を公開しました。実際、最初に読んでからこの投稿を続けると便利な場合があります。
注： この投稿は、修正プログラムのインストールを思いとどまらせることを意図したものではなく、パフォーマンスへの影響がどのようなものかを理解することを目的としています。環境を保護するためにすべての修正をインストールし、この投稿を使用して、ハードウェアなどをアップグレードする必要があるかどうかを判断する必要があります。
どのようなテストを行いますか？
2つの通常の基本的なワークロードタイプ、OLTP（小さな単純なトランザクション）とOLAP（大量のデータを処理する複雑なクエリ）について見ていきます。ほとんどのPostgreSQLシステムは、これら2つのワークロードタイプの組み合わせとしてモデル化できます。
OLTPには、PostgreSQLで提供される有名なベンチマークツールであるpgbenchを使用しました。両方を読み取り専用（-S）でテストしました ）および読み取り/書き込み（-N ）3つの異なるスケールのモード– shared_buffers、RAM、およびRAMよりも大きいサイズに適合します。
OLAPの場合、TPC-Hにかなり近いdbt-3ベンチマークを使用し、2つの異なるデータサイズを使用しました。RAMに収まる10GBとRAMよりも大きい50GBです（インデックスなどを考慮）。
>
提示された数値はすべて、2x Xeon E5-2620v4、64GBのRAM、およびIntel SSD 750（400GB）を搭載したサーバーからのものです。システムは、GCC 7.3でコンパイルされたカーネル4.15.3でGentooを実行していました（完全なretpolineを有効にするために必要です） 修理）。同じテストは、i5-2500k CPU、8GBのRAM、および6x Intel S3700 SSD（RAID-0内）を備えた古い/小さいシステムでも実行されました。ただし、動作と結論はほとんど同じであるため、ここではデータを提示しません。
いつものように、両方のシステムの完全なスクリプト/結果はgithubで入手できます。
この投稿は、軽減のパフォーマンスへの影響に関するものなので、絶対数に焦点を当てるのではなく、パッチが適用されていないシステム（カーネルの軽減なし）と比較したパフォーマンスを見てみましょう。 OLTPセクションのすべてのチャートが表示されます
(throughput with patches) / (throughput without patches)
数値は0％から100％の間で、値が大きいほど良い（緩和の影響が少ない）と予想されます。100％は「影響がない」ことを意味します。
注： 違いをより明確にするために、y軸は75％から始まります。
OLTP/読み取り専用
まず、このコマンドで実行された読み取り専用pgbenchの結果を見てみましょう
pgbench -n -c 16 -j 16 -S -T 1800 test
次のグラフで示されています：
ご覧のとおり、ptiのパフォーマンスへの影響 メモリに収まるスケールの場合、約10〜12％であり、ワークロードがI/Oバウンドになるとほとんど測定できなくなります。さらに、pcidの場合、回帰は大幅に減少します（または完全に消えます）。 有効になっています。これは、PCIDがx86の重要なパフォーマンス/セキュリティ機能であるという主張と一致しています。 retpolineの影響 はるかに小さい–最悪の場合は4％未満であり、ノイズが原因である可能性があります。
OLTP/読み取り/書き込み
読み取り/書き込みテストは、pgbenchによって実行されました。 これに似たコマンド：
pgbench -n -c 16 -j 16 -N -T 3600 test
期間は、複数のチェックポイントをカバーするのに十分な長さであり、-N （小さな）ブランチテーブルの行でのロックの競合を排除するために使用されました。相対的なパフォーマンスは、次のグラフに示されています。
回帰は読み取り専用の場合よりも少し小さく、pcidがない場合は8％未満です。 pcidでは3％未満 有効。これは、WALへのデータの書き込み、チェックポイント中の変更されたバッファのフラッシュなど、I/Oの実行により多くの時間を費やした結果です。
ただし、奇妙な点が2つあります。まず、retpolineの影響 スケール100では予想外に大きく（20％近く）、retpoline+ptiでも同じことが起こりました。 スケール1000。理由は明確ではなく、追加の調査が必要になります。
OLAP
分析ワークロードは、dbt-3ベンチマークによってモデル化されました。まず、RAM全体（すべてのインデックスなどを含む）に収まるスケール10GBの結果を見てみましょう。 OLTPと同様に、絶対数にはあまり関心がありません。この場合、絶対数は個々のクエリの期間になります。代わりに、nopti/noretpolineと比較した場合の速度低下について見ていきます。 、つまり：
(duration without patches) / (duration with patches)
緩和策によって速度が低下すると仮定すると、0％から100％の間の値が得られます。ここで、100％は「影響なし」を意味します。結果は次のようになります：
つまり、pcidなし 回帰は、クエリに応じて、通常10〜20％の範囲です。そしてpcid 回帰は5％未満（通常は0％に近い）に低下します。繰り返しになりますが、これはpcidの重要性を裏付けています 機能。
50GBのデータセット（すべてのインデックスなどで約120GB）の場合、影響は次のようになります。
したがって、10 GBの場合と同様に、回帰は20％未満であり、pcid それらを大幅に削減します–ほとんどの場合0％に近いです。
以前のグラフは少し雑然としています。22のクエリと5つのデータ系列があり、1つのグラフには少し多すぎます。したがって、これは3つの機能すべて（pti）の影響のみを示すグラフです。 、pcid およびretpoline ）、両方のデータセットサイズについて。
結論
結果を簡単に要約するには：
-
retpolineパフォーマンスへの影響はほとんどありません - OLTP –
pcidを使用しない場合、回帰は約10〜15％です。 、およびpcidで約1〜5％ 。 - OLAP –
pcidがない場合の回帰は最大20％です 、およびpcidで約1〜5％ 。 - I / Oバウンドワークロード（たとえば、最大のデータセットを持つOLTP）の場合、メルトダウンによる影響はごくわずかです。
影響は、少なくともテストされたワークロードでは、最初の見積もり（30％）よりもはるかに低いようです。多くのシステムは、ピーク時に70〜80％のCPUで動作しており、30％はCPU容量を完全に飽和させます。しかし実際には、少なくともpcidの場合、影響は5％未満のようです。 オプションが使用されます。
誤解しないでください。5％の低下は依然として深刻な後退です。これは確かに、PostgreSQLの開発中に気になることです。提案されたパッチの影響を評価するとき。ただし、これは既存のシステムで問題なく処理できるものです。CPU使用率が5％増加すると、システムがegdeを超える場合、Meltdown/Spectreがなくても問題が発生します。
明らかに、これはMeltdown/Spectreの修正の終わりではありません。カーネル開発者はまだ保護の改善と新しい保護の追加に取り組んでおり、Intelや他のCPUメーカーはマイクロコードの更新に取り組んでいます。また、研究者が攻撃の新しい亜種を見つけることができたため、脆弱性の考えられるすべての亜種について私たちが知っているわけではありません。
ですから、今後さらに多くのことがあり、パフォーマンスへの影響がどのようになるかを見るのは興味深いでしょう。