サーバーと仮想マシン

Linuxカーネルにおけるメモリプレッシャー：ホスティングシステムへの影響

Linuxカーネルにおけるメモリプレッシャーは、ホスティングシステムに直接影響を及ぼします。プレッシャーが高まると、CPU時間とI/Oが負荷の高い処理へとシフトします。 リクレイム, 、応答時間が長くなり、OOM（メモリ不足）のリスクが高まります。ここでは、メモリの負荷をどのように検知・測定・緩和するかを明確に説明し、 ホスティング-ワークロードに常に適切に対応する。.

中心点

私は、ホスティング環境におけるパフォーマンスや障害を左右する重要な調整要素に焦点を当てています。以下のポイントは、私が診断と最適化を行う際の指針となります。この概要を把握することで、「RAMが満杯」という誤った解釈を避け、真の圧力適時に。.

PSI指標 単なる稼働状況だけでなく待ち時間を表示し、遅延を早期に把握できるようにします。.
スワップ負荷 I/Oやレイテンシを悪化させるリクレイムの問題を指摘しています。.
Cgroupsの制限 サービスごとに、スロットリング、保護、およびOOM時の挙動を制御する。.
キャッシュの置換 Webおよびデータベースのパフォーマンスに直接影響を与えます。.
キャパシティ・プランニング また、チューニングを行うことでヘッドルームを確保し、スラッシングを防ぐことができます。.

このようにして、カーネルからアプリケーションに至るまで分析を体系化し、適切な対策を優先順位をつけて実施しています。焦点は、測定可能な効果, 、請負仕事ではない。.

Linuxカーネルにおける「メモリプレッシャー」とは何を意味するのでしょうか？

メモリプレッシャーとは、カーネルがユーザープロセスの処理を続行する代わりに、メモリの解放に目に見えるほど時間を費やしている状態を指します。この場合、リクエストが待機している間、CPUはスキャン、書き込み、エヴィクションの処理に多くの時間を費やすことになります。私は「RAMがいっぱい」と「利用可能なメモリが不足している」を明確に区別しています。 ヘッドルーム“「：キャッシュが『満杯』の状態は健全であり、ボトルネックが発生するのは、リクレイムへの投資が増加した時である。カーネルは非アクティブなリストをスキャンし、書き込みを行う」 dirty-ページを削除し、ファイルキャッシュを破棄し、ウォーターマークを下回った時点で匿名ページをオフロードします。重要なのは、これらの処理に要する時間であり、これはタスクの待機時間や応答時間の延長として現れます。ホストは、95 %の利用率であれば、キャッシュを容易に回収できる限りスムーズに動作しますが、利用率が低い場合、アクティブな匿名ページを追い出さなければならないと、著しく動作が停滞することがあります。.

PSIの理解と測定

Pressure Stall Information（PSI）は、メモリの占有率ではなく遅延を測定するため、メモリへの負荷を可視化します。 /proc/pressure/memory 「some」と「full」が表示されています。「some」は、少なくとも1つのタスクがメモリを待機している状態を表し、「full」は、すべてのタスクが待機している状態を示しています。例：「some avg10=4.67」とは、過去10秒間に4.67 %の時間がメモリ不足によるストール状態だったことを意味します。「full avg10=0.30」は、まれに発生する完全なストールを示しています。私は、「some」値の上昇を早期にレスポンス時間と関連付け、深刻なOOMが発生する前にスケーリング、チューニング、または負荷軽減を行います。この視点により、一見「空き容量が多い」ように見えるRAMに惑わされることを防げます。なぜなら、高速なアクセスができない空きページは リクレイム-その機会をほとんど活用していない。.

測定変数	目安	症状	アクション
PSIメモリの一部（avg10）	> 2–3 % 持続中	応答時間が長くなっている	RAMのヘッドルームを確認し、Cgroupのリミットを微調整する
PSIメモリ満杯 (avg10)	> 0.1 % 顕著	ダウンタイムが短い	原因を特定し、スラッシングを解消する
メモ使用可能	< 10 %（RAM）	バッファが小さい	キャッシュ／ワークロードの負荷軽減、キャパシティの計画
vmstat si/so	常に > 0	スワップ圧力	Swappiness／スワップの調整、Hotsetの保護

ホスティング環境における症状

処理が活発なホストでは、CPU負荷は一見すると中程度にとどまっているように見えますが、まずレイテンシの急上昇が見られます。カーネルはリクレイムループに陥り、I/Oが滞り、リクエストが待機状態になっています。コアには空きがあるように見えるにもかかわらず、多くのタスクがメモリやI/Oでブロックされているため、ロードアベレージは上昇します。これは、負荷が高まっていることを示す典型的な兆候です。印刷. vmstat で si/so の値が継続して表示されている場合、システムがスワップ処理を行っていることを示しており、これにより TLS ハンドシェイク、動的コンテンツ、およびクエリパスが遅延します。この状態を放置すると、システムはスラッシングに陥ります。つまり、CPUは有益な処理を行う代わりに、ページングやスワッピングにほとんどの時間を費やすことになります。事態が深刻化すると、OOMキラーが作動し、スコアの高いプロセスを強制終了させます。これに対処するには、対象を絞った OOMキラーの分析パターンや設定ミスを特定するのに役立ちます。.

ホスティング・ワークロードおよびCgroupsとの関連性

共有環境では、メモリを大量に消費するアプリケーションが1つあるだけで、多くのクライアントのレイテンシが増加してしまいます。Cgroupsはその影響を緩和しますが、リソース配分が不適切な インスタンス. VPSやクラウドインスタンスでは、RAMの割り当てが不足していたり、スワップ戦略が不適切だったりすると、負荷の急増がより早く発生します。隔離は他のサービスを保護しますが、自身のサービスまでは保護しません。データベースは大きなバッファプールに依存しています。Reclaimによってこれらが追い出されたり、スワップが発生したりすると、クエリ時間が長くなり、スループットが大幅に低下します。コンテナオーケストレーションでは、memory.low、memory.high、memory.max を使用して、重要なサービスを保護し、ストールを抑制し、緊急時には対象を絞って終了させます。そのため、私は意図的に制限値を設定し、サービスごとの PSI を監視して、適時に是正措置を講じ、重要なサービスのための予備容量を確保しています。 ワークロード 空けておくこと。.

モニタリング戦略と指標

MemAvailable、Buffers、Cachedを確認して、短期的にどれだけのメモリを回収できるかを把握しています。MemFreeの値だけを見ると、誤解を招きやすいからです。同時にvmstatも確認しています。si/soの値が持続している場合は、スワップ圧が高まっていることを示しており、これがI/Oを大幅に増加させ、レイテンシを上昇させます。その背景については、スワップ利用率私は実績のある診断パターンを活用しています。PSIは、「some」と「full」が実際の遅延を定量化してくれるため、不足していた要素を補ってくれます。これにより、閾値に達した際にアラートを発し、負荷のピークと慢性的なボトルネックを区別しています。 sarやオブザーバビリティ・スタックによる時系列データはパターンを可視化し、チューニングの成果を確認するのに役立ちます。dmesgは、ハードリミットや設定ミスを示唆するOOMイベントを明らかにします。こうして、カーネルの視点、I/Oの挙動、および 申し込み.

負荷がかかった状態での代表的なワークロード

Nginx や Apache などの Web サーバーは、バックグラウンドで Reclaim や Swap が実行されていると、コンテンツの配信速度が低下します。Keep-Alive 接続が長時間開いたままになるため、キューがさらに長くなります。PHP や Python のスタックは、フレームワークのキャッシュ、JIT データ、セッションデータによって RAM を占有します。スワップが発生すると、これらのデータはRAMとストレージの間を行き来し、応答時間を大幅に延長します。バッファプールが縮小したり、その一部がスワップ領域に追いやられたりすると、データベースの処理速度は低下します。I/Oごとのわずかな追加レイテンシであっても、処理数が多くなると累積して クエリ. RedisやMemcachedのようなキャッシュサービスはRAMへのアクセスが不可欠です。キー領域がスワップ領域に追いやられてしまうと、その利点は失われ、負荷がかかった際にプロセスが強制終了されるリスクが高まります。いずれの場合も、メモリがボトルネックになっていることを示す最も明確な指標となるのは、PSIやスワップのメトリクスであり、 CPU.

システムのチューニングとカーネルパラメータ

まずは vm.swappiness から始めます。設定値を適度に低くすることで、必要なリクレイムを妨げることなく、過度なスワップの使用を防ぎます。その効果は PSI を使って一貫して測定しています。その後、vm.dirty_ratioおよび関連する制限値を最適化し、長時間のフラッシュの波を引き起こさないようにしつつ、微小な書き込みの乱発も防ぎます。これら両方の調整には、顕著な効果レイテンシについて。Cgroups v2 では、重要なサービスには memory.low を、過負荷時のスロットリングには memory.high を、そして制御可能な OOM を伴うハードリミットとして memory.max を設定しています。NUMA トポロジーには特に注意を払っています。グローバルにはまだ RAM の空きがあるにもかかわらず、ローカルで負荷がかかる可能性があるからです。プロセスおよびメモリのバインディングを設定することで、こうした落とし穴を回避できます。最後に、ページキャッシュの挙動を確認します。不要な置換はヒット率を低下させ、WebやDBのワークロードにおいて直接的な時間損失につながります。これに加え、ページキャッシュの最適化有益な知見を提供してくれる。.

Reclaimパスへの詳細な考察

対策を的確に選ぶために、私は次のように区別しています。 kswapd そして ダイレクト・リクレイム. kswapd は、ウォーターマークを下回った場合に非同期で動作します。十分に回収しやすいキャッシュが存在する限り、その動作は比較的穏やかです。Direct Reclaim は、スレッドが緊急にページを必要とする際に、実行コンテキストに同期的に介入します。ここで、ユーザーに実感されるような処理の停滞が発生します。私は、リクレイムがファイルキャッシュと匿名ページのどちらを主に対象としているかを観察しています。カーネルが主にファイルキャッシュを追い出す場合、キャッシュミスが発生しやすくなります。一方、匿名メモリ（ヒープなど）を追い出す場合は、ハードストップやスワップ活動が発生する恐れがあります。最新のワーキングセットメカニズムは、有用なページをより長く保持するためにリフォールト距離を考慮しています。それにもかかわらず、繰り返しのリフォールトが多数見られる場合は、ホットセットが利用可能な ヘッドルーム となった。.

さらに、ディスクの圧縮とデフラグにも注意を払っています： kcompactd 大規模な割り当てなど、関連する領域を作成しようと試みたり、 THP. 圧縮処理が遅れると、kcompactd の CPU 使用率の上昇、レイテンシの増加、および負荷のピーク時に「full」状態の PSI の割合が増加するのが確認できます。このような場合、単に「スワップを増やす」のではなく、負荷を下げたり、THPポリシーを調整したりするほうが、多くの場合、より理にかなっています。.

スワップ戦略の詳細

スワップは敵ではなく、ツールです。しかし、誤って使用すればレイテンシを悪化させる要因となります。私は次のように区別しています：

スワップなし: スワップラグには強いが、ピーク時にはリスクが高い――OOMが発生するタイミングが早まり、Reclaimには予備のバッファがない。.
適度なスワップ 高速なSSD上：アクセス頻度の低い匿名ページをスワップアウトするのに適している。swappinessとcgroupの制限を適切に設定しておけば、RAM内のホットセットを保護できる。.
zswap/zram: 圧縮によりI/O負荷が軽減されるため、I/O負荷の少ないホストや、一時的な負荷の急増に対するバッファとして適している。CPUの処理能力がボトルネックにならないよう、CPUリソースの割り当てと圧縮率を確認する。.

swappinessを一律に低く設定するわけではありません。ファイルキャッシュの容量が大きいワークロードでは、使用頻度の低い匿名ページを押し出し、ファイルキャッシュを安定した状態に保つために、swappinessを少し高く設定するのが有効です。重要なサービス（データベースなど）については、memory.lowを設定し、必要に応じてRAM内のホットセットをロックすることで、スワップによって誤って影響が及ばないように保護しています。重要なのは、 vmstat si/so 戦略を調整した際、PSIが一貫して低下する場合、そうでない場合は修正を加えます。.

THP、圧縮および断片化

透明な巨大ページ（THP） TLBヒットを削減し、CPU負荷が高くメモリを多用するアプリケーションのパフォーマンス向上に寄与します。ただし、負荷が高くなるとコンソリデーション処理が発生し、「always」設定では大幅なストールにつながる可能性があります。私は、「madvise」を恩恵を受けるワークロード（特定のインメモリエンジンなど）に的を絞って使用し、レイテンシに敏感なWebスタックでは、THPを意図的に無効にするか、madvise経由でのみ許可するようにしています。さらに、以下の点を監視しています。 vm.compaction_proactiveness そして、能動的な圧縮処理が停滞を先送りしているだけなのか、それとも実際に減少させているのかを確認する。THPページが頻繁に分割されたり、圧縮処理が過熱したりする場合は、量が不足していることを示唆している。 ヘッドルーム あるいは、アプリケーションにおける不適切なリソース割り当てパターン。.

NUMAトラップとローカルプリント

NUMAホストにおいて、グローバルな「空きRAM」は一見しただけでは判断が難しいものです。あるソケットが負荷にさらされている一方で、別のソケットが未使用のままになっている場合があるためです。私はNUMAの統計情報を確認し、プロセスをローカルに固定（CPU／メモリバインディング）することで、ホットセットが計算負荷の近くに留まるようにしています。グローバルな空きリソースがあるにもかかわらず、あるノードでダイレクト・リクレイムが発生している場合は、NUMAの不均衡を示しています。このような場合、広範囲に分散したサービスにはインターリーブ割り当てを、モノリシックなワークロードには厳格なバインディングを適用することが有効です。 cgroupごとのPSIをNUMA統計と組み合わせることで、個々のノードがキューを生成しているかどうかを確認できます。.

アプリケーションに即した対策

私は、ps、top、htop、およびプロファイラツールを使用してメモリ使用状況のプロファイルを分析し、真のメモリ消費源やリークを特定しています。その際、ホットセットが時間の経過とともにどのように変化するかに注目しています。アプリケーションのキャッシュサイズは慎重に選定しています。大きすぎると負荷がかかり、小さすぎるとパフォーマンスが低下するためです。直感ではなく、PSIや応答時間を基準に調整を行います。リソース圧迫の兆候が確認された場合、アプリケーションは重要度の低いキャッシュや一時データを自主的に解放できるようにします。これにより、グローバルな制限を変更することなく、ストールを低減します。起動パラメータやGCチューニング（JVMなど）は、ワーキングセットがRAM内に適切に収まるよう調整します。また、バッチ処理を行うことで、過度なメモリ割り当てパターンを緩和します。ビルドアーティファクトやデバッグシンボルにも常に注意を払っています。見落とされた残骸は、知らぬ間にリソースを消費してしまうからです。 メモリ そして、その後の失速のリスクを高めます。.

Cgroups v2の細かなポイントとOOM戦略

Cgroups v2 を使用することで、保護、スロットリング、およびハードリミットを明確に分離しています： メモリ.low 重要なサービスのためにヘッドルームを確保し、残りのリクレイムは重要度の低いグループに割り当てられます。. メモリ.high 上限を超えた場合、的を絞ったスロットリングによって処理を抑制し、システムに支障が出る前にアプリケーションにメモリを解放させます。. メモリ.max これが最後の防衛ラインだ――これを越えると、制御された範囲内でOOMが発生する。私は 生販在 cgroupごとに設定し、ストールが発生した場所でアラームが作動するようにします。個々のサービスがダウンしても、グローバルなPSIは安定した状態を保ちます――まさにこのパターンを検知したいのです。OOM優先度と組み合わせて、明確な犠牲ルールを設定します。重要度の低いバッチワーカーが最初に終了し、コアAPIは ヘッドルーム.

仮想化：バルーニング、KSM、オーバーコミット

仮想化環境では、二重のプレッシャーに直面します。ゲストからはRAMが空き状態に見える一方で、ハイパーバイザーは バルーン を奪う。この操作により、双方のリクレイムコストが増加する。ホスト側のPSIを測定し、ハイパーバイザーのメトリクスと相関分析を行う。バルーニングイベント時にPSIが上昇する場合、そのVMにはホスト側でより多くの保証容量、あるいはより適切なCgroupポリシーが必要である。. KSM 同一ページの重複排除によりRAMを節約できますが、CPU負荷がかかります。同種のVMが多数存在するホスティング環境では、追加のCPU負荷がSLOを脅かさない限り、この手法を採用する価値があります。オーバーコミット（例：多数の小型VMを積極的に割り当てること）については、固定のSLO予備容量を確保し、厳格な メモリ.low レイテンシが重要なシステム向け。.

ホスティングにおけるアーキテクチャ上の決定

個々のインスタンスにかかる負荷のピークを軽減するため、水平分散を採用しています。スケーラブルなプールは異常値を緩和し、レイテンシを低く抑えます。役割は明確に区分しています。データベース、アプリケーション、キャッシュにはそれぞれ独自のリソースプールを割り当て、リクレイム処理がシステム境界を越えて予期せぬ副作用を引き起こさないようにしています。ストレージの選定にあたっては書き込みレイテンシを重視しています。ダーティページフラッシュは応答時間に直接影響するため、高速なパスは、リクレイム時間を顕著に短縮します。クラスタ環境では、ノードごとにRAMの予備容量を確保し、スケジューラポリシーを通じて負荷とメモリ使用量が均等に分散されるよう制御します。 PSIしきい値を用いてスケーリングを自動化し、「some」値の上昇によって、システムが急停止したり、キル-出来事に関連して。.

生産能力計画とヘッドルーム・モデル

ヘッドルームについては、測定可能な基準で定義しています。つまり、通常のピーク時でも「some」PSIが定義された閾値を下回るよう、十分な余裕を確保し、「full」状態が実質的に発生しないようにしています。そのためにパーセンタイル（例：1時間あたりの負荷の99パーセンタイル）を活用し、ワークロードの変動性に応じて10～30 %分の追加RAMを計画します。データベースにはより大きな固定余力を割り当て、Webフロントエンドはより動的にスケーリングします。リバウンド時間を調整します：ピーク後にPSIやsi/soはどのくらいの速さで低下するでしょうか？数値が高いままの場合、それは予備容量が不足しているか、スワップ／ダーティ戦略が適切でないことを示しています。このようにして、キャパシティ計画は年1回の推定ではなく、継続的なプロセスとなります。.

アラーム通知とSLO制御によるチューニング

PSIをユーザーSLOと連動させています。「some avg10」がAPIのレイテンシと同時に上昇した場合は、対応措置を講じます。アラームは「黄色」（2～3 %の「some」が持続し、「full」が0に近い状態）と「赤」（5 %を超える「some」、または「full」が0.1 %を超える状態）の2段階に設定しています。 cgroupベースのアラームは、ノイズの多い少数派を特定するのに役立ちます。さらに、ダーティキューや書き込み待ち時間の増加に対してもアラームを設定し、ダーティの波を適時に平滑化できるようにしています。目標は、チューニング対策（Swappiness、memory.high、キャッシュサイズ）が可視化され、元に戻せるようにすることです。変更は段階的に適用し、同じメトリクスを用いて変更前後の比較を行っています。.

日常生活における段階的な診断

まず、`free -h` と `MemAvailable` を確認します。値が著しく低下した場合は、適切に解放できるキャッシュや、ホットセットが増加しているサービスを探します。その後、`vmstat` を短い間隔で実行し、シ/ソの傾向を把握します。継続的なスワッピングは負荷の高まりを裏付け、I/Oパスへの手がかりとなります。続いて、`/proc/pressure/memory`を読み取り、10秒、60秒、300秒における「some」と「full」の値を評価します。平均値の上昇は、観測されたレイテンシと直接関連付けます。 dmesgはOOMの痕跡を示し、どのプロセスが直近でメモリ危機を引き起こしたか、あるいは影響を受けたかを明らかにします。そこからCgroupの制限値と優先度を導き出します。これらすべてをもとに仮説を立て、小さなチューニングを段階的に実施し、PSIで検証を行い、 応答時間 一目瞭然。

ランブックと典型的な原因の連鎖

ある種のパターンには、何度も出くわします：

バックアップやスキャンジョブはページキャッシュを追い出す: 突然、キャッシュヒット率が低下し、Web／DBの処理速度が低下する。対策：ジョブの処理を抑制する（I/O優先度）、実行時間帯をずらす、ジョブのcgroupに対して`memory.high`を設定する、重要なサービスのページキャッシュ予算を確保する。.
ワーカープロセスの脆弱性: 匿名メモリが徐々に増加しており、PSI「some」が数時間にわたって上昇し続けている。対策：メモリリークを特定し、自動再起動／リサイクルポリシーを導入するとともに、メモリリークがホスト全体に悪影響を及ぼさないようメモリ制限を設定する。.
THPに起因する失速: トラフィックのピーク時にkcompactdの負荷が上昇する。対策：THPを「madvise」に設定し、影響を受けるサービスを調整し、圧縮パラメータを確認し、ヘッドルームを増やす。.
NUMAローカル印刷: グローバルRAMに空きがあるにもかかわらず、あるソケットでスラッシングが発生している。対策：アフィニティを修正し、広範囲に分散したワークロードに対してはインターリーブを設定し、スケジューラでの負荷分散を調整する。.
低速ディスクでのスワップ: si/soが増加すると、応答時間が急激に悪化する。対策：スワップ領域をより高速なストレージに移行し、zswap/zramの導入を検討し、swappinessおよびcgroupポリシーを最適化する。.

各ランブックは検証で締めくくられます。「some/full」が発生し、レイテンシが安定しているでしょうか？もしそうでない場合、仮定が間違っていたか不完全だったことになります。その場合は、さらに反復処理を続けます。.

運用におけるツールとトレース

従来のツールに加え、私はより詳細な視点に立っています。具体的には、ページキャッシュとアノンの比率、ページフォールト率、リフォールトのパターン、およびライトバックキューを監視しています。 eBPFやトレース手法を用いることで、リクレイムパス沿いやライトバック処理中、あるいは大容量ブロックの割り当て時など、待ち時間が発生している箇所をピンポイントで特定できます。私にとって重要なのは、リソース消費が少なく本番環境でも運用可能な計測手法です。つまり、アクティベーションウィンドウを短くし、連続サンプリングではなくサンプリング方式を採用し、アプリケーションのメトリクスとの明確な相関性を確保することです。そうすることで、パラメータを大規模に調整する前に、原因を特定することができます。.

要点と今後の取り組み

メモリプレッシャーとは、単にRAMが使用されている状態ではなく、メモリ不足によって生じる時間のロスを指します。私はPSIを用いてこれを測定し、傾向を早期に把握して、データに基づいた対応を行っています。 MemAvailable、vmstat si/so、PSI、dmesgを総合的に分析することで、レイテンシの急上昇やスラッシングの真の原因を突き止めることができます。スワピネス、ダーティ、Cgroupのチューニングにより、ストールを的確に低減し、重要なサービスに十分なリソースを確保しています。 ヘッドルーム. アーキテクチャレベルでは、水平分散、明確に区分された役割、そして高速なストレージパスが、あらゆる負荷ピークの影響を緩和します。結局のところ重要なのは、診断と対策を継続的に連携させることです。測定し、調整し、再び測定する――パフォーマンスと 安定性 また合う。.