GNU / Linuxで利用可能なプロセス情報についていくつかの質問があります。プロセスファイルシステム。これは、最初はアプリケーションからvmPeak、vmSize、vmRSS、vmHWMを抽出したいという要望によるものでした。
/proc/<pid>/status人間が読めるバージョンは、/proc/<pid>/stat機械が読めるという仮定から始まります。
kernel.org コメント:
stat - プロセス状態
status - 人間が読める形式のプロセス状態
私は気づいたとき、これは正しいことではないことに気づきました。仮想ピークでのみ購入できます/proc/pid/status。
/proc/pid/status実際には、複数の場所の価値を組み合わせてそれ自体の価値をいくつか追加するようです。
我々が/proc/pid/status使用する理由がある場合/proc/pid/stat？それが必要なのはなぜですか？
APIが2つあるのはなぜですか？廃止されたか/proc/pid/stat役に立ちますか？
stat同等ではありません。より少ない数のフィールドを提供します。解析するのは少し簡単です（使用無邪気にすると、微妙なエラーが見つかる可能性があります。）。 statを使用するすべてのプログラムは、状態を使用するように簡単に切り替えることができます。実際に何個も壊れることがありますか？
私は両方のパーサーを作成しました（たとえAPIがあまり役に立たなかったため、統計用にパーサーを使用しましたが）。機械が読めるコンテンツはあまりありません。実際、「状態」のパーサーは、必要なすべての種類のKey-Valueストアに直接読み取ることができるため、よりエレガントになります。状態は、すべての言語で解析する方が簡単でスケーラブルです。
実際、「状態」ではなく「状態」に依存するプログラムはいくつですか？そのうち実際にこれが提供できる微細な解析速度が必要なものはありますか？
今、私は以前のバージョンとの互換性のために統計を長年にわたって削除することができないことを理解していますが、維持しなければならない合理的な理由がなければ、「もう使用されていません」と言うことができます（これは私の質問に対する可能な答えになります）です）。
パフォーマンスが問題の場合、仮想ファイルシステムを介してこのカーネル情報をテキストに変換して逆に変換するパフォーマンスは、ライブラリ呼び出しのパフォーマンスよりもかなり低いです。
常に新しいAPIを追加するのは面倒です。この回答提案ですが、ほとんどが安定していることを考えると、CライブラリAPIがないのはなぜですか？システムメッセージ？
ベストアンサー1
カーネルが以前のバージョンとの互換性を提供するのは、/proc/…/stat単に古いバージョンのプログラムと互換性があるのではなく、古いバージョンと互換性があるからです。今ユーティリティをビルドすると、次のプログラム（、など）procpsが生成されます。pspgreppidofまだ読んでいます/proc/…/stat。
一つできるprocps代わりに使用することも可能です/proc/…/status。以前のパフォーマンスパラメータは関連性がなくなり、statusカーネルからの検索には検索と同じ時間がかかりますstat。ただし、これはユーザースペースツールを変更せずにカーネルを更新したい既存のシステムには役立ちません。
カーネルに関する限り、これは予約されていますstat。Linuxカーネルにユーザースペースを絶対に破壊しないというポリシーがあるのはなぜですか？
もちろん、単に使用するか完全に避けることを自由に選択でき/proc/…/statusます/proc/…/stat。私は後者がもはや廃止されたと見なされるべきであるという一般的な合意を知りません。議論されたことはなく（議論されていないという意味ではありません）、廃止されたとマークされていません。マニュアルprocfsページまたはカーネルの古い ABI シンボル（/procアイテムが含まれています）。たぶんそれはただ慣性かもしれません。より多くのカーネル開発者が気付くかもしれないサークルにこの問題を提起するならば、明らかにそこにあります。はい意見一致。
（私が知っている限り、いくつかのフィールドはstatで利用できません。少なくともプロセスグループとセッションIDは。）status
sysinfoインターフェイススタイルについていつでも提案できます。テキストベースのインターフェイスは、以前のバージョンとの互換性を維持するためにのみ消えるわけではありません。 Unixスタイルシステムの多くのテキスト処理ツールで利用可能な形式でこの情報を保存することは、削除するのに便利です。