問題/背景
systemd-nspawnコンテナのFedora 32で実行される(管理された)Postgres 10.16インスタンスがあります.定期的にメトリックでは、「システム」CPU使用率が大幅に急増していることがわかります。これは、Postgresクエリスループットとディスクアクティビティの急激な減少に関連して30秒から数分まで続きます。さらに、インジケータコレクタは10秒ごとではなく不規則な間隔で収集します。この問題は約1日に1回発生します。 *
手がかり
前回このようなことが発生したときにいくつかの診断を実行した結果、ほとんどの低パフォーマンス期間中に次のことがわかりました。
- kswapdはコアを100%使用しています。
- 定期的なダンプを見ると、変更に対する変更の割合が0.014であることが
/proc/vmstatわかります。pgsteal_kswapdpgscan_kswapd
つまり、kswapdはページキャッシュからページを回収しようとしているようですが、回収するすべてのページについて約70ページを調べる必要があります。このマニュアルページ0.3未満の割合は、懸念される原因であることを示します。イベントの1つの50秒間、kswapdは合計230万ページをスキャンし、そのうち32,000ページだけをリサイクルしました。
私は、この病理学的なページキャッシュ除去の動作がこれに関連するパフォーマンスの問題に関連していると疑います。私もこれがpostgresがここでコンテナで実行されているという事実に関連していると思います。似ているが同じではない質問です。（残念ながら、この決定はホスティングプロバイダによって異なるため変更できません。）しかし、この動作の原因が具体的に何であるか、根本原因を見つけるか解決する方法はよくわかりません。
質問
2つの関連する質問があります。
- どのようなメモリ/ディスクアクセスパターンがリサイクルを非効率的にすることができますか？
- 次回このような場合にどのような情報を収集できますか？または、可能性を狭めるためにデバッグするにはどうすればよいですか？
付録：私が考慮し、拒否した仮説
この本ページリサイクル効率が低い2つの理由は次のとおりです。
このアルゴリズムのパフォーマンスが低下する可能性がある状況は2つだけです。最初は、リサイクル候補が主に匿名ページであるかどうかです。この場合、Linuxはプロセスページテーブルを直線的にスキャンする前に、回収するページを検索する前に多数のページをチェックしますが、幸いなことにこれはまれです。
/proc/meminfo非アクティブページのかなりの部分が「匿名」ではなく「ファイル」であることを示す同時ダンプがあります。これは、ほとんどのシステムメモリをページキャッシュに割り当てることを推奨するPostgresの一般的な現象です。だから私はそれが私たちに適用されないと思います。
2番目のケースは、単一プロセスのinactive_listに頻繁に記録されるファイルサポート常駐ページがたくさんあることです。プロセスとkswapdは、これらのページを常に「クリーンアップ」し、何も公開せずにinactive_listの先頭に配置するループに入ることができます。この場合、2 つのリスト サイズ間の比率は依然として大きく変化しないため、active_list から inactive_list に移動するページはほとんどありません。
vmstatダンプによると、nr_dirtiedイベント期間中は約33kしか追加されませんが、pgscan_kswapd2.3mが追加されました。したがって、kswapdはページを書くよりもはるかに速くページをスキャンでき、それも問題ではありません。
* 50％以上のコアと2倍のRAMを持つ大規模なオーバープロビジョニングインスタンスにアップグレードしたため、まだこれは発生していません。