管理者向けLinux procfs：重要なファイルの概要

仝 Linux procfs /proc 配下の仮想ファイルを通じて、カーネルの現在の状態を表示します。システム管理において特に重要なのは、負荷、メモリ、プロセス、ファイルディスクリプタ、およびブロックデバイスです。 重要なのは、これらの値の性質を見極めることです。一部の値はその時点のスナップショットですが、他の値は起動からの累積値や移動平均値である場合があります。したがって、単一の値だけを鵜呑みにせず、適切なシグナルや、ホスト、VM、コンテナのコンテキストと照らし合わせて確認してください。.

procfsの理解：データストレージの代わりにカーネルが提供する仮想ビュー

仝 procfs これは仮想ファイルシステムです。/proc 配下のエントリは、実行中の Linux カーネルのデータ構造や状態を表しています。これらは、ストレージデバイス上に永続的に保存された内容として存在しているわけではありません。 読み取りの際、カーネルはその時点の状態に基づいて対応するビューを生成します。再起動後、多くのカウンタはリセットされます。そのため、/procは監視および一部の制御を行うためのインターフェースであり、独自のファイルや永続的な設定を保存する場所ではありません。.

管理上、3つの領域を区別する必要があります。/proc/meminfo、/proc/stat、/proc/loadavg などのグローバルステータスファイルは、カーネル全体の指標を提供します。/proc/1234 のような数値名のディレクトリは、個々のプロセスに関する詳細情報を提供します。 一方、/proc/sys にはカーネルパラメータが格納されており、権限やパラメータの設定によっては、読み取り可能であると同時に書き込み可能となる場合もあります。ファイル形式が似ているからといって、ステータスの照会と設定の変更が根本的に異なる結果をもたらすという事実に惑わされてはなりません。.

利用可能なパスやフィールドは、Linuxシステムごとに異なります。カーネルのバージョンや設定、アーキテクチャ、認識されたハードウェア、および読み込まれたモジュールが、表示されるエントリに影響を与えます。また、ネームスペースによっても個々の表示内容が変化します。 特に、PIDネームスペースに関連付けられたprocfsは、プロセスおよびPIDのビューを制限しますが、からといって、グローバルなファイルが自動的にコンテナやcgroup固有の値を表示するとは限りません。 スクリプトでは、どこでも同じ完全なprocfs構造を前提とするのではなく、ファイルやフィールドを評価する前に、その内容を確認する必要があります。.

これとは区別して、/sys にある sysfs があります。これは主にデバイス、ドライバ、ハードウェアオブジェクトを表しています。また、リソースの割り当てやグループの制限に関しては、cgroup2 も関連しています。しかし、初期診断に必要な多くのカーネルおよびプロセスの状態については、procfs が依然として直接的な情報源となっています。.

カウンター、スナップショット、可視性を正しく位置づける

procfs では、この値だけでは問題の原因を説明できることはめったにありません。まず、その時間的な関係性を明確にする必要があります。一部のデータは 累積カウンター システム起動以来の値を示すものもあれば、現在の状態を表すもの、あるいは移動平均の時間を表すものもあります。 カウンタ値が高いということは、ひとまず、起動以降にイベントが累積してきたことを示すに過ぎません。レートは、2つの測定値から初めて算出されます。つまり、値の差をその間の時間間隔で割ったものです。これは、例えば多くのCPUカウンタ、割り込みカウンタ、およびディスクカウンタに当てはまります。.

/proc/uptime ファイルは、経過稼働時間と集計されたアイドル時間を提供します。これは、起動以降のカウンター値を時系列で把握するのに役立ちますが、測定データ系列の代わりにはなりません。 1回限りの照会は「その時点のスナップショット」に過ぎません。傾向、ピーク、あるいは周期的な負荷について信頼性の高い結論を導き出すには、タイムスタンプ付きの繰り返し照会が必要です。その際、カーネルは動作を続けているため、読み取り中に値が変化する可能性があります。.

表示されるデータにも限界があります。/proc/self は、常にそのパスを解決しているプロセスを指します。そのため、PID を仮定することなく、スクリプトや対話型の検証に実用的です。 しかし、他のプロセスのディレクトリへのアクセスは、ファイル権限、Linuxキャパビリティ、および procfs マウントオプションによって制限される可能性があります。 hidepid 制限される。この場合、情報が確認できないのはprocfsの不具合ではなく、機密性の高いプロセス情報の読み取りを防ぐための保護措置である。.

コンテナ内では特に注意が必要です。PID ネームスペースにバインドされた procfs は、プロセス関連のパスについて、そのネームスペースのビューに属するプロセスしか表示しません。 一方、/proc/meminfo、/proc/stat、/proc/diskstats などのグローバルカーネルファイルは、引き続きホストの値を反映しており、コンテナの制限に自動的に制限されることはありません。 したがって、診断を行う前には、その問題がプロセス、グローバルなカーネル値、あるいは実際に割り当てられたリソースのいずれに関係するかを明確にする必要があります。また、コンテナの制限値や使用状況については、cgroup2の分析も併せて行う必要があります。.

/proc/sys での読み取り、設定、およびセキュリティ対策

この分野 /proc/sys これは、sysctl インターフェースのファイルシステムビューです。値の読み取りは、診断を目的としています。 一方、書き込みアクセスは実行中のカーネルの動作を直接変更し、サービス、リソース消費、またはセキュリティ機能に影響を与える可能性があります。再起動なしで変更が反映されるからといって、リスクがないわけでも、自動的に永続的になるわけでもありません。永続性は、選択されたシステム構成によって異なります。.

ディレクトリ構造は、初期の分類を容易にします。/proc/sys/fs には、グローバルなファイルシステムパラメータやファイルハンドルパラメータなどが格納されています。/proc/sys/vm にはメモリ管理の設定がまとめられており、/proc/sys/net にはネットワーク関連のパラメータが含まれています。 利用可能なサブディレクトリやキーは、カーネルの設定やシステムの機能によって異なります。したがって、存在するパラメータが必ずしも普遍的なチューニングの指針となるわけではなく、そのドキュメントと具体的なワークロードが重要な判断基準となります。.

一見最適化されているように見えるものの、実際にはそうではない例として挙げられるのは drop_caches /proc/sys/vm 配下。カーネルのドキュメントでは、この機能をデバッグやテストに限定しており、再利用可能なキャッシュをクリアするとパフォーマンスが低下する可能性があるため、これらの目的以外での使用は推奨していません。 空きメモリが少ないこと自体は、キャッシュを破棄する理由にはなりません。カーネルは、ファイルキャッシュにも意図的にRAMを使用しているからです。.

変更を行う前には、常に明確な理由が存在すべきです。まず初期値を記録し、変更の目的と予想される副作用を文書化してから、管理された条件下で変更を行い、その後、関連する測定値やサービスの動作を観察してください。 変更を元に戻す手順を事前に計画し、専門的な検証を経て初めて、その値を恒久的な構成に反映してください。パラメータとその管理に関するより詳細な基礎知識については、以下の記事で解説しています。 Linuxホスティングにおけるカーネルチューニング：一目でわかるSysctlパラメータ.

管理タスク別の主要な procfs ファイル

procfs ファイルの選択は、できるだけ完全なディレクトリ一覧を目指すのではなく、管理上の観点に基づいて行うべきです。グローバルファイルは多くの場合カーネル全体の値を提供し、プロセスパスは単一の可視プロセスを記述し、/proc/sys/fs 以下のエントリは設定やシステム全体の制限値を提供します。 値の中には現在の状態を示すものもあれば、起動以降に蓄積されたカウンタや移動平均を示すものもあります。この区別によって、1回の読み取りで済むか、それとも2回の測定ポイントが必要かが決まります。.

この表は問題の特定の手がかりであり、診断の流れそのものではありません。異常な値が検出された場合は、常に独立した裏付けが必要です。具体的には、CPUおよびI/Oデータによる負荷、Pressure Stall Informationによるメモリ値、サービスの動作によるプロセス指標などです。特に /proc/diskstats および /proc/stat は 累積カウンター; 既知の範囲内でのその差は、絶対値よりもレートについてより有意義な情報を提供する。 コンテナ内では、ファイルがグローバルなカーネル値を提供しているのか、それともcgroupごとに利用可能なビューを提供しているのかを確認する必要があります。そのため、以下のセクションでは、シグナルを負荷、メモリ、プロセス、I/Oの順に分類しています。.

負荷、CPU、メモリ：信号を組み合わせて評価する

システムの動作が遅い場合、/proc/loadavg は参考になる指標ですが、CPUの状態を判断する決定的な指標ではありません。この3つの値は、過去1分、5分、15分の平均負荷を表しています。 負荷には、実行可能な状態（R）にあるスケジューリングユニットだけでなく、I/O などによる中断不可能な待機状態（D）にあるタスクも含まれます。4番目のフィールドには、現在実行可能なスケジューリングユニットと、存在するすべてのスケジューリングユニットの数が表示されます。高い 負荷平均 したがって、これはCPUの競合、I/Oアクセスのブロック、あるいはその両方を示している可能性があります。.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

/proc/stat の CPU 行には、システム起動以降の USER_HZ 単位での時間割合が含まれています。これに基づいて負荷率を算出するには、2 つのクエリ結果を比較する必要があります。単一の測定値だけでは、累積時間しか示されません。 なお、iowaitの値はストレージの直接的なレイテンシ指標ではありません。その計算には文書化された限界があり、特定の状況下ではむしろ低下することさえあります。したがって、I/Oが原因であるかどうかを判断するには、デバイス値やI/O-PSIも併せて確認することが有用です。.

MemFreeの値が低くても、必ずしもRAM不足を意味するわけではありません。Linuxは、未使用のメモリをキャッシュとして効果的に活用しています。MemAvailableは、スワッピングなしで新しいアプリケーションがどれだけのメモリを確保できるかを推定するもので、状況の初期判断には通常、こちらの方が役立ちます。 MemAvailableが不足し、同時にメモリストールが発生して初めて、 ストレージの圧力. ただし、コンテナ内では、これらのグローバルなメモリ値はホストに由来する場合があります。保証されたリソースや制限されたリソースについては、cgroup2 の視点もさらに重要となります。.

/proc/pressure にあるファイルは、この見方を補完するものです。「memory」および「io」において、「some」とは、時間枠の一部において少なくとも一部のタスクが進行不能になったことを意味し、「full」は、アイドル状態ではないすべてのタスクが同時にブロックされていた状態を表します。 avg10、avg60、avg300 はそれぞれ 10 秒、60 秒、300 秒を指し、total は累積ストールカウンターです。 CPU に関しては、システム全体の「full」は意味論的に定義されておらず、互換性の理由から Linux 5.13 以降では null として出力されます。したがって、システムレベルでの診断値として解釈すべきではありません。CPU、memory、io の各 PSI はそれぞれ異なる情報を提供しているため、互いに置き換えて使用すべきではありません。.

MemFreeが低い状態でサービスの応答が遅い場合は、まずMemAvailableと/proc/pressure/memoryを確認してください。両方に異常が見られない場合、システム全体にわたる深刻なメモリ不足の可能性は低いと考えられます。 続いて、/proc//status を確認することで、対象のプロセスが VmRSS の値が閾値に近づいている、スレッド数が非常に多い、あるいは異常な状態にあるかどうかを判断できます。この組み合わせにより、キャッシュに依存しているものの正常なメモリ使用状況と、さらなるプロセス分析を必要とする問題とを区別することができます。.

プロセス、ファイルディスクリプタ、およびディスクI/Oの調査

確実に存在するプロセスを用いて安全に演習を行うため、$$は現在のシェルのPIDを表します。statusファイルは、フィールド指向のstatファイルよりも人間が読みやすい形式です。 Nameはプロセスを識別し、Stateはその状態、PPidは親プロセス、Threadsはスレッド数を表します。VmRSSは常駐メモリの近似値であり、そのRSS管理はスケーラブルかつ非同期で行われるため、不正確になる可能性があります。一方、VmSizeは仮想アドレス空間を表します。 FDSizeは記述子テーブルのサイズを表しており、必ずしも現在開かれているエントリの数を示すわけではありません。自発的および非自発的なコンテキストスイッチは、スケジューリング挙動の分類に役立つ場合がありますが、それだけではエラーの証拠とはなりません。.

cat /proc/$$/status
ls -l /proc/$$/fd

fdディレクトリには、開かれているファイル、パイプ、デバイス、またはソケットへのシンボリックリンクが含まれています。これは、例えば、削除されたログファイルを依然として開いたままにしているプロセスを見つけるのに役立ちます。 ただし、プロキシ、データベース、あるいはイベント駆動型サーバーでは、多数のファイルディスクリプタが開かれていることは十分に想定されます。フィルタリングされたビューやプロセス間のマッピングについては、 lsof を使用して開いているファイルを分析する 適切な補足です。cmdline からのコマンドラインは機密性の高い引数を漏らす可能性があります。environ は、アクセス情報やトークンが含まれる可能性があるため、さらに機密性が高く、ルーチン的な照会には適していません。.

maps コマンドは、権限、オフセット、デバイス、iノード、および場合によってはパスを伴う仮想メモリ領域を一覧表示します。smaps コマンドは、各マッピングごとに詳細なメモリ値を追加し、RSS の情報に比べてより正確ですが、処理に時間がかかるスナップショットを提供します。 どちらのファイルも、詳細なメモリ分析を目的としています。出力量は膨大になる可能性があり、個々のマッピングを解釈するには文脈が必要です。ざっと確認するだけなら、通常は`status`やシステム全体のメモリファイル、PSIファイルの方が効率的です。.

負荷が高く、CPU使用率が低い場合、/proc/diskstats はデバイスレベルでの診断情報を提供します。 このファイルは、ブロックデバイスごとに累積的なI/O統計情報を記録します。アクティビティをレートとして評価するには、2つの時点を比較する必要があります。その際、物理ドライブ、パーティション、および仮想デバイスやデバイスマッパーデバイスを明確に区別しなければなりません。異なるレベルのカウンタを無闇に合算してはなりません。 プロセスのオープンファイルディスクリプタは、diskstatsのデバイスカウンタに直接割り当てることはできません。その間には、ファイルシステム、キャッシュ、マッピング層が存在するからです。 とはいえ、/proc/pressure/io と組み合わせることで、観測される I/O ストールとデバイスのアクティビティが時間的に一致しているかどうかを確認することは可能です。.

procfsの運用：照会、監視、およびデータ保護

再現性のある動作診断を行うには、procfs クエリを測定ポイントとして扱う。具体的には、タイムスタンプ、システムコンテキスト、および具体的なクエリを記録する。多くの値は起動以来の累積カウンターであり、2つの値の差を時間間隔で割って初めてレートが算出される。これは、例えば以下のカウンターに当てはまる。 /proc/diskstats. したがって、単一のクエリではアクティビティを確認することはできるが、スループットや持続的な性能低下を確実に定量化することはできない。.

モニタリングシステムは、一定の間隔で、とりわけ以下のデータなどの記録値を /proc/meminfo, 機器の測定値から /proc/diskstats, 、プロセスおよびシステムの状態、ならびにカーネルによるサポートが利用可能な場合は印刷信号を収集する。生データを適切な単位に変換し、カウンタについては差分を算出し、履歴を保存しなければならない。 コンテナ内では、グローバルなprocfs値をワークロードのリソース制限と同一視してはならない。プロセスパスはPIDネームスペースに制限される場合がある一方、メモリやデバイスの値はホストの状態を反映している場合があるためである。グループごとの制限や使用率を把握するには、補足的なcgroup2メトリクスが必要となる。 時間的な推移を把握して初めて、信頼性の高い閾値を設定できます。予想される負荷の範囲内に収まる高い値は正常である可能性がありますが、自身のベースラインに対して急激な上昇が見られる場合は、多くの場合、より重要な指標となります。利用可能な procfs エントリは、実行中のカーネルとその設定によって異なります。.

ダイレクトファイルとツールは互いに補完し合っています。. ps, top 或いは htop インタラクティブなプロセスビューに適している；; free, vmstat, iostat, pidstat, ss そして sar インストール環境によっては、特定の質問に対応するためにデータを準備します。カーネルソースを直接確認したり、小規模で追跡可能なスクリプトを作成したりする場合は、procfsが依然として有用です。アラート通知やキャパシティプランニングにおいては、時系列データの方が適している場合がほとんどです。.

読み取り専用のクエリにおいても、可視性の制限が適用されます。アクセス権限、マウントオプション、およびPIDネームスペースにより、プロセスデータが表示されない場合や、コンテナのビューに限定される場合があります。 逆に、独自の /proc マウントがあるからといって、すべてのグローバルカーネルファイルにそのコンテナのデータのみが含まれているとは限りません。したがって、プロセスエントリが欠落していたり、グローバル値が予想外に高かったりする場合、まずは実行環境、マウントオプション、および cgroup コンテキストを確認する必要があります。.

サービスの遅延やリソースのボトルネックに対する診断手順

トラブルシューティングは、原因と推測される個々の値ではなく、症状から始めるものです。その後、少なくとも1つの独立した信号を確認し、その現象がホスト、仮想マシン、またはコンテナのいずれに影響しているかを特定してください。 そうすることで、例えば、高い負荷を安易にCPUの問題と決めつけたり、多数のオープンデскриプタを安易にリークと断定したりすることを避けられます。以下の手順は、初期診断の指針となるものであり、アプリケーション関連のログに代わるものではありません。.

ロード平均が高い場合は、まずその数値を押し上げているのが実行中のタスクか待機中のタスクかを確認します。 負荷の数値は、1分、5分、15分間の平均値を示しており、R状態とD状態の両方が考慮されています。そのため、CPU時間の項目とI/O負荷やデバイスアクティビティを比較する際は、慎重に行う必要があります。特に iowait これを、単にメモリレイテンシとして解釈してはならない。.

処理速度が遅く、MemFreeの値が小さい場合、 メモ使用可能 より適切な最初のコンテキスト値。メモリPSIと、対象となるプロセスのステータス（VmRSS、スレッド数、状態など）を追加してください。PSIでは、メモリとI/Oについて以下のように区別しています。 some 部分的にブロックされているタスクについて、および full 非アイドルタスクを完全にブロックするため。PSIファイルが存在しない場合、その原因はカーネルの設定や環境にある可能性があり、ボトルネックではないことを示すものではない。.

ファイルおよびプロセスの診断については、権限と PIDネームスペース その意味合いを制限してしまう。 コンテナ環境では、/proc は多くの場合、割り当てられたプロセス空間のみを記述しています。そのため、アクセスが拒否されたりディレクトリが不完全だったりする場合は、データの欠如から技術的な結論を導き出す前に、ユーザー権限、procfs のマウントオプション、およびネームスペースのコンテキストを確認してください。.

よくある誤解を正し、適切なツールを選ぶ

Linuxの管理において、4つの誤解がしばしば誤った対応を招きます。ほとんど MemFree カーネルはメモリをキャッシュなどとして利用しているため、これだけで自動的にRAM不足を意味するわけではありません。新しいアプリケーションにとっては、MemAvailableの方がより信頼性の高い指標となります。また、高いロード率はCPUの飽和状態を示すものではありません。これは、中断不可能な待機タスクも計算に含まれるためです。 iowaitの割合が高いからといって、ストレージデバイスの直接的なレイテンシを測定しているわけではありません。また、procfsはすべての環境で同一というわけではありません。カーネルバージョン、設定、ハードウェア、モジュール、ネームスペースなどが、ファイルやフィールドに影響を与えます。.

質問に応じて手法を選択してください。特定の事象の原因分析を行う場合は、 procfs 現在実行中のカーネルからの生のデータ。迅速かつ人間が読みやすい概要を把握するには、専用のコマンドラインツールの方がたいてい効率的です。 傾向の把握、アラート通知、あるいは容量に関する意思決定が重要な場合は、測定ポイントを時系列で整理し、カウンターの差分を計算し、過去の比較値を保持できるモニタリングが必要です。 個々のサービスやコンテナのリソース制限に関しては、cgroup レベルでの分析がホスト全体のビューを補完します。適切な設定を行えば、PSI を cgroup 単位で利用することも可能です。.

特に慎重を要する点は以下の通りです。 /proc/sys. パラメータの読み取りは診断であり、書き込みはカーネルの動作を変更します。値を変更するのは、原因が把握され、初期値が記録され、影響が確認でき、かつ元に戻す方法が確立されている場合のみに限定してください。ディレクトリ fs, vm そして net パラメータをテーマ別に分類していますが、普遍的なチューニングの指針を示すものではありません。.

例 drop_caches これは、介入と最適化の違いを示しています。カーネルのドキュメントでは、このインターフェースを非破壊的であると説明していますが、パフォーマンス上の問題が生じる可能性があると警告しており、テストやデバッグのシナリオ以外での通常の運用措置としては推奨していません。 したがって、保守的なルールとしては、「まず測定を行い、次に根拠に基づいた限定的な変更を加え、その効果と副作用を観察し、その決定を文書化すること」が挙げられます。.