管理

Linux PSI：正確なパフォーマンス分析と監視

Linux PSI タスクがCPU、メモリ、またはI/Oでどれくらいの時間待機しているかを示す指標を提供し、それによって真のボトルネックを可視化してくれます。これにより、単に負荷を測定するだけでなく、システムがいつブロックしているかを的確に把握でき、Pressureの値からパフォーマンス分析やモニタリングのための直接的な対策を導き出すことができます。.

中心点

一部／全部: 早期警告信号 vs. 重大な停滞
CPU/メモリ/I/O: リソースごとの印刷数を明確に区分
avg10/60/300: トレンド評価の時間枠
Cグループ: 原因者と影響を受けた者を特定する
トリガー: 閾値を超えた場合に自動的に反応する

Linux PSIが測定するものと、それが重要な理由

これから読み上げます プレッシャー-メトリクスにより、CPU時間、RAM、またはI/Oの不足によってプロセスがどれだけの実際の作業時間を失っているかを測定します。従来の利用率指標はリソースがどの程度使用されているかを示すのみですが、PSIはシステムが実際に停止している頻度を明らかにします。まさにこの点こそが、短い待ち行列と完全な停止との違いを明らかにするのです。コンテナや高密度なデプロイメントが組み合わさった動的な環境では、これによりボトルネックを早期に検知し、特定のリソースに明確に割り当てることができます。こうして、チューニング対策を的確に優先順位付けし、根本原因に関する当て推量を省くことができるのです。原因.

LinuxでPSIを有効にして確認する

まず、以下のディレクトリにあるファイルを確認して、PSIが有効になっているかどうかを調べます。 /proc/pressure 読み込みます。CPU、メモリ、I/Oの値がそこに表示されていれば、準備は完了です。データがない場合は、カーネルのブートパラメータ「psi=1」でPSIを有効にするか、カーネルで「CONFIG_PSI=y」が設定されていることを確認します。この機能はカーネル 4.20 以降で利用可能であり、最新のディストリビューションでは多くの場合、すでに有効になっています。簡単な確認には、cat /proc/pressure/cpu といった単純なコマンドを実行するだけで十分で、これにより avg10、avg60、avg300、および total の値が得られます。これにより、数秒のうちにシステムが有意義な指標を提供する。

/proc/pressure にあるファイルについて理解する

/proc/pressure には、以下の3つのファイルがあります。 CPU, memory および io は、それぞれ「some」と「full」の 2 種類の出力形式を持っています。「some」は少なくとも 1 つのタスクが待機を余儀なくされたことを示し、「full」はアイドル状態ではないすべてのタスクが同時にスタックしていることを示します。さらに、10秒、60秒、300秒の移動平均値と累積合計値も取得しています。これらの時間枠を基準にすることで、一時的なピークと持続的な問題を区別しています。これにより、散発的なピークが発生しているだけなのか、それとも持続的な圧力が利用できる。

「some」と「full」の実践的な使い方

私は「some」を先行指標として、「full」を深刻なアラートと見なしています。というのも、「full」は生産的な作業が事実上停止している状態を指すからです。CPUの「some」値が上昇した場合は、スケジューリング、ロック、負荷分散を確認します。その際、スレッドの最適化やスケジューラのレイテンシを測定する. memory-some の値が高い場合は、多くの場合、ページリクレイム、スワッピング、あるいは負荷の高いメモリ割り当てが示唆されています。io-some が増加している場合は、キュー、優先順位、および競合するアクセスを確認します。私は直感ではなく、明確な基準に基づいて判断を下します。信号.

システム全体での評価とCgroupベースの評価

まず、システム全体について検討します 価値観, 全体像を把握するために、その後Cgroupsに切り替えて原因を特定します。cgroup v2を使用すると、サービスやコンテナごとに個別のpressureファイルが見つかるため、Pod、Slice、またはUnitへの割り当てが可能になります。このアプローチにより、すべての負荷を一概にホストのせいにするのではなく、症状と原因を明確に区別できます。その後、クォータ、CPUシェア、メモリ制限を的確に調整します。これにより、公平性を高め、相互の影響.

モニタリング、ダッシュボード、KubernetesにおけるPSI

私はPSIを手動で収集することはめったにありませんが、エクスポートツールを使ってデータを 時系列 データを収集し、ダッシュボードで傾向や相関関係を可視化します。Kubernetesでは、ノード、ポッド、コンテナの各レベルでPSIを読み取ることで、ワークロードごとの消費量とボトルネックを明確に区別できます。これにより、個々のPodが他のPodの待ち時間を増加させているのか、それとも問題がノード全体で発生しているのかを把握できます。アラートは、フル開発時や「some」値が持続的に高い場合に設定しています。これにより、ユーザーが待ち時間を経験する前に、先手を打って対応することができます。 感じる.

代表的な利用シナリオと適切な閾値

負荷テストではPSIを活用し、CPU、メモリ、またはI/Oの負荷によって応答時間が上昇するかどうか、またその現象が一時的なものか恒常的なものかを確認しています。キャパシティプランニングでは、avg300を監視して反復的なパターンを把握し、適切なタイミングでリソースを拡張したり、ワークロードをシフトしたりしています。オートスケーリングでは、フル状態になる閾値に近いトリガーを設定し、タイムリーに対応できるようにしています。パフォーマンスの緩やかな低下が見られる場合は、リリース前後のベースラインを比較して、その影響を明確に把握します。こうして事実に基づいて判断し、最も効果が発生します。

PSI指標の表形式による簡易チェック

PSIを確認する際、正しい仮説に素早くたどり着けるよう、簡単な分類基準を用意しています。以下の表は、リソースごとの「some」と「full」の解釈をまとめたもので、最初の対応策を示しています。これは詳細な分析の代わりにはなりませんが、運用において貴重な時間を節約してくれます。重要なのは、短時間のピークと長期間の傾向を区別して評価することです。まさにそのために、私は移動平均値であるavg10、avg60、avg300を コンテクスト.

リソース	some-Signal	full信号	よくある原因	考えられる対策
CPU	時折生じる待ち時間	すべてのタスクがブロックされています	スケジューラの競合、ロック、スレッドの過剰	スレッドプールの調整、ロックの緩和、CPUシェア／クォータの調整
メモリー	リクレイム、ページフォールト、割り当てのボトルネック	強い売り圧力、スワップが市場を支配	オーバーコミット、大きなヒープ、キャッシュの圧迫	リミットの確認、配分の最適化、スワッピングの削減
入出力	長くなる行列	I/Oは包括的な概念である	ディスク／ネットワークの過負荷、競合するアクセス	優先順位、バッチ処理、キューのチューニング、ボリュームの分離

貯蔵圧力の正しい解釈

私は、memory.pressureをRSS、キャッシュ率、スワップ使用率と組み合わせて評価しています。なぜなら、この組み合わせによって初めて信頼できる知見が得られるからです。多くの場合、someの値が高い背景には、集中的なメモリ解放の段階やページフォルトの増加があり、これらはより適切な割り当てパターンによって平滑化できます。「full」が表示された場合は、実験を中止し、まずリミットの設定やキャッシュの積極性を抑えることで負荷を軽減します。このテーマについてさらに深く掘り下げるには、メモリプレッシャー RAMチューニングに関する実用的なヒント。これにより、制御不能なスワッピングによる応答時間の悪化を防ぐ 支配している.

I/Oのボトルネックを特定し、対処する

io.pressureについては、レイテンシ、リキューレート、キューの深さと併せて確認しています。なぜなら、スループット値だけではボトルネックが見えにくくなるからです。負荷が中程度であるにもかかわらずsome値が高い場合は、アクセスプロファイルに不均一性があることを示唆していることが多く、これはバッチ処理や優先順位付けによって平滑化できます。ファーストバイトラグが発生し、フル状態が増加している場合は、非同期I/Oによるデカップリングと、ホットパス用の独立したボリュームの活用を重視しています。詳細な診断には、一連の測定データと、日常的に実績のある以下のガイドを活用しています。 I/O待機時間の分析. それによって、私は的を射た判断を下すことができ、代わりに 前提条件.

PSI 対負荷平均および従来の指標

私は、これらの視点間のギャップを埋めるために、意図的にPSIをロードアベレージ、CPU使用率、iowait、メモリ使用率と並べています。cpu.pressureが低い状態で負荷が高い場合、それは多くのタスクがアクティブに計算処理を行えていることを示しているだけであり、システム全体のボトルネックが発生していないことを意味することがよくあります。逆に、CPU使用率が中程度であるにもかかわらずcpu.pressureが上昇している場合は、スケジューラ間の競合やロック競合の兆候である。 I/Oに関しては、iowaitだけではシステム全体がどれほど影響を受けているか判断できませんが、io.pressureは、その過程でどれだけの作業時間が失われているかを定量化します。まさにこの「使用率」から「失われた時間」への変換こそが、私の意思決定の信頼性を格段に高めてくれるのです。.

avgウィンドウを正確に読み取る

私は、avg10/60/300という値を、タスクがブロックされていた時間の割合として捉えています。 avg10が2.50であるということは、過去10秒間に、潜在的な稼働時間のうち2.5%が失われたことを意味します。total値は、起動以来のストール時間を（高精度な時間単位で）累積したものであり、それによって私に 曲線下の面積. 生産能力計画の際には、総量と日次プロファイルの傾きを確認しています。ピーク時に曲線が明らかに急勾配になる場合は、負荷軽減策を計画します。運用シグナルについては、パターンを評価しています。avg10での一時的な上昇は、構造的な圧力を示唆するavg60とavg300の並行した上昇に比べ、それほど懸念材料とはなりません。.

Cgroupsの実践：構造、パス、権限

私はcgroup v2を使用しており、各サービス、スライス、またはPodのディレクトリ内に直接pressureファイルを配置しています。これにより、ユニット、Pod、またはコンテナごとに、負荷がローカルで発生しているのか、それとも単に転送されているのかを判別できます。この方法により、systemdユニット、Kubernetesポッド、およびユーザー定義グループを明確に区別することができます。割り当てが成功すれば、的を絞って調整を行います。CPUクォータはより厳しく、CPUシェアはより公平に、メモリ制限は現実的な値に設定します。実務上、私は制限を設定しているまさにそのCgroup、つまり効果が現れる場所で測定を行うようにしています。これにより、根本的な原因には手を付けずに、ある箇所で発生している症状だけに対処してしまうことを防げます。.

アラート過多を招かないアラート戦略

私は、傾向や持続性を考慮に入れてアラームを設定しています。早期検知のため、しきい値を「some」に設定し、観測ウィンドウやヒステリシスと組み合わせて、avg10が そして avg60は高いまま維持される。緊急の介入については、「full」を短い時間枠と自動対応（スケーリング、優先順位付け、スロットリング）に紐づけています。フラッターを避けるため、状態が複数回確認されてから初めてトリガーを起動し、値が復帰閾値を大幅に下回ってから元に戻すようにしています。アラートはサービスのSLOに紐付けています。p95レイテンシが上昇し、同時に負荷が増加している場合、その所見は信頼性が高いとみなします。負荷率のみでは、私にとっては不十分だからです。.

実例：私がすぐに見分けられるパターン

私は、意思決定を迅速化してくれるため、繰り返し現れるパターンを集めるのが好きです：

CPU：「コア数が足りない」ではなく「ロック競合」“ – CPU使用率が限界に達していないにもかかわらず、cpu.someの値が上昇している。ホットロックを調査し、スレッドの分散を縮小し、バックプレッシャーを用いてピーク値を平滑化している。これによって、コア数を増やすよりも大きな効果が得られることが多い。.
メモリー：リクレイム・スパイラル – memory.some は、スワップが有効になると、ページフォルトの発生に伴い上昇・変動します。そこで、キャッシュの積極性を下げ、ヒープのピーク（バッチサイズなど）を縮小し、制限値を調整することで、memory.full が表示されるのを未然に防ぎます。.
I/O：不均衡なアクセス – io.someの値が上昇する一方で、通常のスループットは維持されています。読み取り／書き込みパスを分離し、小規模なI/Oをバッチにまとめ、ホットパスを個別のボリュームに分散させます。これにより、必ずしも純粋なスループットを向上させることなく、待ち時間を短縮しています。.

解釈における限界と課題

PSIが測定しているのは「待ち時間」であり、絶対的な負荷率ではないことを念頭に置いています。CPUに依存するバッチジョブは、利用可能なコア数が十分にある限り、cpu.pressureを上昇させることなく高い負荷率を示すことがあります。逆に、スループットが低くio.pressureが高い場合は、明らかなボトルネックである可能性があります。また、仮想化環境では、リミットやアフィニティがローカルなボトルネックを引き起こしていないか確認します。少数のコアにのみピン留めされているコンテナは、ホストに空きリソースがあるにもかかわらず、高いcpu.pressureを示すことがあります。また、システム全体とcgroupローカルの視点を比較することも重要です。そうして初めて、問題を正しい場所で解決できているかどうかを判断できるからです。.

運用上のガイドライン：サンプリング、オーバーヘッド、および可視化

サンプリングはシンプルにしています。平均値ウィンドウによってすでに平滑化されているため、運用上の意思決定には1～5秒の間隔で十分です。PSIのオーバーヘッドは無視できる程度だと考えています。特に、測定をシステムに近い状態で行い、適切に配置された少数の時系列データのみを収集しているためです。可視化のため、リソースごとにパネルを並べて表示し（some/full、avg10/60/300、total）、それらをレイテンシやエラー率と相関分析しています。事後分析では、総計の推移をデプロイ、リリース、または設定変更に対してプロットします。これにより、どの対策が実際に負荷を軽減しているかが明確になります。.

リソースごとの的を絞った対策

私は、反射的にハードウェアを追加することなく、これらのパターンから具体的な手順を導き出します：

CPU: スレッドプールとコンカレンシーガードを制限し、ホットロックを緩和（粒度／ロック戦略）、負荷を公平に分散（シェア／クォータ）、トポロジーを考慮（NUMA、アフィニティ）。ローカルでの負荷軽減が効果を示さない場合にのみ、水平または垂直方向にスケーリングを行います。.
メモリー: メモリ割り当てを安定させる（バッチ処理、バッファ）、キャッシュを抑制する、制限値を現実的な値に設定する、ヒープの使用量の急増を緩和する、スワップの影響を軽減する。memory.someはメモリ割り当てのパターンに敏感に反応するため、変更の前後で重点的に測定を行っている。.
入出力: アクセスプロファイルの平滑化（バッチ処理、非同期I/O）、ホットパスの分離、優先順位の設定、キュー深度の適切な選択、および競合するワークロードの分離。成果は、io.pressureの低下とP99レイテンシの短縮によって評価しています。.

チームの日々の業務におけるPSI：コミュニケーションと主体性

私はPSIを、プラットフォームチームとプロダクトチーム間の共通言語としても活用しています。単に「遅い」といった抽象的な表現で話すのではなく、リソースとパターンを具体的に指定します。「サービスXにおいて、過去20分間の『io.some avg60』が4%を超えている」や、「cgroup Yで『memory.full』がトリガーされた」といった具合です。このように正確に特定することで、どの担当者が対応すべきか、またどのリソース（時間、リソース）を投入すれば最大の効果が期待できるかが明確になり、優先順位付けが容易になります。定義されたベースラインに基づき、技術的に妥当であり、かつステークホルダーにも理解しやすい品質目標を合意形成しています。.

トリガー、ベースライン、段階的な展開

私は、閾値と監視期間を設定したPSIトリガーを使用し、負荷が持続した場合にデーモンが自動的に反応するようにしています。信頼性の高い判断を行うため、変更を行う前に、典型的な負荷フェーズに基づくベースラインを作成し、後で新しい測定データと比較しています。アラートは保守的に定義しています。「some」で高負荷が継続している場合は対応の猶予を与え、「full」で対策を発動させます。大規模な環境では、ノイズを回避し、許容範囲を適切に調整するために、PSIベースのアラートを段階的に導入しています。これにより、私のモニタリングは クリア かつ堅実でありながら、チームに不要な通知を押し付けることはありません。.

ホスティング、仮想化、マルチテナントにおけるメリット

PSI を使って、個々のワークロードが他のワークロードのパフォーマンスを低下させていないか、ハードウェアの余力が十分か、どこで制限を調整すべきかを確認しています。共有環境では、個々のアカウントで継続的に発生している CPU、メモリ、または I/O の負荷を把握し、適時にリソースの再配分を計画しています。 Cgroupベースの指標により、どのサービスが影響を受けているか、どこで的を絞って帯域制限や優先順位付けを行うべきかがわかります。これにより、応答時間を安定させ、負荷がかかっている状況でもリソースの公平な利用を確保しています。その結果、コストを削減し、問題の深刻化を防ぎ、ユーザーにとって実感できる品質.

結論：指標から意思決定へ

私はLinux PSIを採用しています。これは待ち時間を定量化し、システム負荷とユーザー体験の間のギャップを埋めてくれるからです。「some」で初期の兆候を検知し、「full」で実際のボトルネックに対応し、「Cgroups」で正確な原因を特定します。ダッシュボード、トリガー、ベースラインにより、こうした可視化が具体的な対策へとつながります。リミットの最適化、負荷分散の改善、I/Oパスのクリーン化などです。PSIを積極的に活用すれば、原因の特定にかかる時間を短縮し、手探りのチューニングを繰り返す手間を大幅に省くことができます。こうして、監視データは明確な決断, 、システムの動作を明らかに高速化する。.