☰

競合/再起動前のプロセスのメモリ使用量を分離します。

tag-icon • tag-icon arch-linux kde manjaro
競合/再起動前のプロセスのメモリ使用量を分離します。

衝突が発生しています（一日に約0.5回）。メモリ使用量が約40％から100％に上がり、1〜2秒間何も起動せずにシステムがハングします。私は反応する時間がなかった。スワップは使用されません。この問題の原因を特定するためにログを表示したいのですが、孤立したプロセスのメモリ使用量ログがどこにあるのかわかりません。

ベストアンサー1

これは、メモリ使用量が急激に増加する一部のサーバーからデータを収集するために数年前に行われた作業です。私のサーバーはこれを数分で行ったので、テクノロジーはデータをキャプチャできました。ほんの数秒でメモリ使用量が急増している場合は、あまり役に立ちません。

私はtopバッチモードを使用し、メモリ使用量に応じて15秒ごとに最初の30プロセスをファイルに書き込みます。このファイルは、メモリの急増イベント後にメモリ使用量が増加したプロセスと、次のようにメモリ使用量がどれだけ早く増加したかを示しています。

LINES=30 COLUMNS=160 top -b -c -o RES -d 15 -n 40 -w  >> /path/to/output.txt

オプション：
topレポートするプロセス数とプロセスごとに表示するコマンドライン数を処理する方法には、いくつかの珍しい点があります。COLUMNS変数もROWSその一部です。-w最後のオプションで説明します。

  • -b行の要約ブロックとプロセスごとの行の出力が強調表示またはページ指定されていないため、出力ファイルに適切に追加されるバッチモードを選択します。
  • -c各プロセスラインのコマンド表示を切り替えます。通常、各プロセスの基本コマンド（例：）を表示するtopように設定され、引数（例）を含むコマンドライン全体を表示するように変更されます。これは、私のようにサーバーに2〜3つのJavaプロセスがあり、そのうちどのプロセスがメモリの急増を経験しているかを知る必要がある場合に便利です。unattended-upgrades-c/usr/bin/python3 /usr/share/unattended-upgrades/...
  • -o RESメモリ使用量に基づいて、各プロセスの行を最大値から最小値までソートします。メモリはKiB単位で測定されます。別のアプローチは、-o %MEMメモリ使用量をメモリ全体のパーセンテージとして提供することである。
  • -d 15各検査プロセス（および出力ラインバースト）の間には15秒の遅延があります。これはtop毎分4回の検査を意味します。
  • -n 4040個のサンプルを選択すると、topコマンドは終了します。合計40個のサンプル（毎分4個）は、最大実行時間10分と終了を意味します。
  • -wコマンドパラメータが切り捨てられないように、各プロセスに対して「広い」（長い）行を選択してください。-w列を指定するパラメータを受け入れることができますが、これによりtop1行が作成されます。みんなプロセスは最初の30個のプロセスだけでなく、コマンドを単純に保ち、topに広い行を表示し、メモリ使用量が最も高い30個のプロセスのみを表示するように接頭辞を-w付けます。マニュアルページには、変数を設定するときにこのオプションは必要ありませんが、無視され、すべてのプロセスに出力されるようです。このオプションは、後に他のオプションがある場合はtopが無効な引数に対して文句を言うので、最後に配置されます。必要に応じて合計値と合計数を調整します。topLINES=30 COLUMNS=160-wLINESCOLUMNStopLINES-wLINESCOLUMNS-d-n

便利な他のオプション：

  • -E要約行のメモリ比率を変更します。 -E mMiBを選択し、-E gGiBを選択します。ただし、各プロセスの行ではなく、要約行のみがあります。
  • -u username各プロセスラインをユーザーとして実行されるラインに制限するusername
  • -p pid,pid各プロセス行をリストのプロセスIDに制限します。

マニュアルページには、オプションの追加フィールド名をtop含む上記のオプションに関する詳細情報が表示されます（フィールド名のクイックリストを表示するには実行）。-otop -O

topコマンドを使用してスクリプトを作成し、10分ごとにcronからスクリプトを呼び出しました。長期実行バックグラウンドプロセスとして機能するためにシェルスクリプトを作成する必要はありませんが、すでに実行されているプロセスで発生したメモリスパイクをキャプチャするという利点があります。

各サンプルには、要約情報を含むラインブロック、1〜2本の空行、30本のプロセスラインがあるため、出力ファイルはソフトウェアで簡単に解析できません。しかし、当時は手動でファイルを確認するだけで十分でした。小さな勝利：要約行にはタイムスタンプが組み込まれており、ピークイベントの直前にファイルの一部を見つけるのに非常に便利です。

Linuxシステムでは、個々のプロセスのメモリ消費量をキャプチャする他の方法があり、これよりも優れている可能性があります。私はちょうど私に合った方法を渡すだけです。それがあなたにも効果があることを願っています。

おすすめ記事