CPUでの短期CPU集約プロセスの追跡/監視

CPUでの短期CPU集約プロセスの追跡/監視

そのため、しばらくこの問題に取り組んできましたが、この問題を解決するツールを見つけるのに苦労しています。この問題が存在すると想像する必要があります。私の問題の基本は次のとおりです。

  • 私たちは、preempt-rtパッチで4コアRHEL5 / centos5を実行し、少数のアプリケーション(fifoスケジューリング、高い優先順位など)に対して合理的な決定性を確保するためにいくつかのタスクを実行しようとします。とにかく、我々は最近のデフォルトよりわずかに高い優先順位でPTPv2クライアントを実行し始めました。 PTPv2クライアントのCPU時間が不足すると、実際にはかなり怖い副作用が発生する可能性があることがわかりました。詳細を見ることなく、比較的短時間でPTPデーモンをバインドしたCPUを何かが捕まえていることがわかります(従来のロギングではこれをキャプチャできなかったからです)。したがって、短いバージョンは、このPTPクライアントをユーザーモード(呼び出しを使用daemon)で起動し、それを特定のCPUにバインドしてtasksetから解放することです。数時間ごとに、PTPクライアントをプリエンプションしたり、約10ms〜500msの間に何らかの理由で実行を防止します。

私はCPU PTPが実行されていることを知っているので、そのCPUで何が起こっているのかを追跡するのは比較的簡単だと思いました。残念ながら、特定のCPUの動作を追跡するのは簡単ですが、与えられた時間に(トップと友達)または最近の時間の集計(sarと友達)を含むが、短い時間(ミリ秒の範囲)しか持続しますが、まれに(毎回)持続するパフォーマンススパイクをキャプチャすることは驚くほど困難です。数時間程度)。私は次のことを試しました(しかし私はそれを正しく使用したと主張しません!したがって、私が誤って正しいツールを使用したと思われる場合は教えてください):

  • htop / top:topと友達は何が起こっているのかを理解するのに非常に便利です。。マルチコアシステムでは、プロセスが最後に実行されたCPUを知らせるオプションを見て、残りは無視する必要があるため、これは少し難しくなります。しかし、しばらく前に問題が発生したか、短期間に発生した場合、何もせずに私がやりたいことをするのは難しいようです。たくさんトップレベルのロギング、非常に頻繁に。 Htopは審美的にもっと良いですが、少なくとも私が望む機能についてはほぼ同じ機能を提供しているようです。

  • sar:sarは時間の経過とともに活動を追跡できるため、より適切なようです。ところで、サルはあなたに言葉をとてもよくしているようです。どのようにシステムは5分、10分、15分前に実行されていましたが、実行されませんでした。なぜそれが行動する方法です。つまり、どのプロセス(ユーザー「プロセス」でも)が問題を引き起こしているかどうかを理解するのは困難です。とにかくロギングと解析を調査中です。場所手動データ。

  • mpstat:mpstatは、見たいコンテンツを興味のあるCPUに簡単に制限できるという点で優れています。しかし、それが提供する情報はかなり不透明です。もしデフォルトでは、(比較的高速なイベントをキャプチャするために)継続的に実行されるようにmpstatを設定しました。もし私の管理者は活動が急増するのを見ていますが、その活動がどこから来たのかを知る方法は多くありません(私が欠けているものがある場合があり、私がここにいるのです!)。

それでは、この問題をどのように解決しますか?私のユーザーエリアPTPデーモンが基本レベルで私が理解したように、ネットワークから絶対時間を取得し、PTPがその時間に近づくようにクロック周波数とティックを歪ませようとするので、混乱していることがわかります。ただし、何らかの理由で(たとえば、PTP飢餓/しばらく実行されていない)、現在の時間と基本時間と考える時間の差が非常に大きい場合(通常> 1秒)、継続的に進行して設定されます。 /時計を歪めずに強制的に実行します。これは時計の大きな変化(この場合は〜200ms以上)を望まないアプリケーションに問題を引き起こしましたが、時計が0.5秒ほどクラッシュするのを見ました。すぐにまたはそれ以上変更されました)…それは私が見たものです。私が言ったように、私たちはタスクをCPUに設定するので、どのCPUで実行されているかを知ることができます。 grub.confにisolcpusがあり、initによって生成されたサブプロセスが特定の(他の)CPUで生成されるように、initの好みも変更しました。したがって、理論的には、どのCPU PTPが実行されるかを完全に制御できます。それでもPTPをブロックしていますが、期待どおりにパケットをキャプチャして追跡するために頭を絞っていました。

参考までに、はい、私はおそらくPTPはカーネルモジュールとして実行する必要があり、PTPデーモンを高い(低)優先順位のFIFOに送信することでこの問題を回避できました。これは問題を解決したようですが、これはより重要です。これは、特定のCPUで時間の経過とともにシステムのパフォーマンスを追跡することに関連する一般的な問題です。そのような問題をどのように解決しますか?

ありがとうございます!どんな助けでも大変感謝します。

ベストアンサー1

私はあなたと同じような問題を抱えていました(Nagiosについて短期間で自宅で書かれた監視アプリケーションを使用しています)。私が思いついた解決策は集めるbash whileループとの組み合わせ。

これは、プロセス名でCollectlを目覚めさせる可能性があるためです。

collectl -sZ -i.1:.1 --procfilt f[your process name]

そして、どのプロセスを呼び出すかをよく知っているので、それを次のループに入れます。

for((i=1;i<10000;i++)); do nohup /path/to/your/app & done

これがあなたの要件に合っているかどうかはわかりません。また、すべての仮想/スタンバイマシンでテストするのが最善です。

おすすめ記事