+スターの公開アカウントをフォローして、エキサイティングなコンテンツを見逃さないようにしましょう
翻訳者 | Zi Mu は床を掃除するのが大好きです
CPU コンテキスト スイッチングは、Linux システムの正常な動作を保証するための中心的な機能です。これは、プロセス コンテキストの切り替え、スレッド コンテキストの切り替え、および割り込みコンテキストの切り替えに分類できます。
この記事では、CPU コンテキストの切り替えの問題を分析する方法についてさらに説明します。
CPUコンテキストスイッチを確認してください
過度のコンテキスト切り替えにより、レジスタ、プログラム カウンター、カーネル スタック、仮想メモリなどのデータの保存と復元に CPU 時間が消費され、システム パフォーマンスが大幅に低下することがわかっています。
コンテキストの切り替えはシステムのパフォーマンスに非常に大きな影響を与えるため、それをどのように確認すればよいでしょうか? そうですね、 vmstat ツールを使用してシステムにコンテキスト スイッチを問い合わせることができます。
vmstat
vmstat これは、一般的に使用されるシステム パフォーマンス分析ツールです。これは主にメモリ使用量の分析に使用されますが、CPU コンテキストのスイッチや割り込みの数の分析にもよく使用されます。
例 vmstat 5(5 秒の出力間隔):
出力を見てみましょう。
cs(コンテキストスイッチ): 1 秒あたりのコンテキストスイッチの数。in(割り込み): 1 秒あたりの割り込みの数。r(running | runnable): レディキューの長さ、つまり、実行中で CPU を待機しているプロセスの数。b(ブロック済み): 中断されないスリープ状態にあるプロセスの数。
33 上記の例では、コンテキストスイッチの数が回、システム割り込みの数が 25 回、レディキューの長さ、および中断されていない状態のプロセスの数がすべて であることが わかります 0。
pidstat
vmstat このツールは、システム全体のコンテキスト切り替えに関する情報のみを提供します。各プロセスの詳細を確認するには、 を使用する必要があります pidstat。オプションを追加すると、 -w プロセスごとのコンテキスト スイッチを確認できます。
例えば：
# Output interval is 5
$ pidstat -w 5
Linux 4.15.0 (ubuntu) 09/23/18 _x86_64_ (2 CPU)
08:18:26 UID PID cswch/s nvcswch/s Command
08:18:31 0 1 0.20 0.00 systemd
08:18:31 0 8 5.40 0.00 rcu_sched
...結果には注意が必要な 2 つの列があります:cswch と nvcswch。このうち、 は1 秒あたりの自発的コンテキスト スイッチcswchの数 を表し、 は1 秒あたりの非自発的コンテキスト スイッチの数 を表します。nvcswch
自発的コンテキストスイッチ: プロセスが必要なリソースを取得できないことによって引き起こされるコンテキストスイッチを指します。たとえば、I/O やメモリなどのシステム リソースが不足している場合、自発的なコンテキスト スイッチが発生します。
非自発的コンテキスト スイッチ: タイム スライスの期限が切れたため、プロセスがシステムによって強制的に再スケジュールされた場合に発生するコンテキスト スイッチを指します。たとえば、多数のプロセスが CPU をめぐって競合すると、不随意のコンテキスト スイッチが簡単に発生する可能性があります。
これら 2 つの概念は異なるパフォーマンスの問題を意味するため、留意する必要があります。
事例分析
これらのメトリクスを確認する方法がわかったので、通常のコンテキスト切り替えの頻度はどれくらいかという別の疑問が生じます。事例を見てみましょう。
sysbench 負荷を生成することで過剰なコンテキストの切り替えの問題をシミュレートするマルチスレッド ベンチマーク ツール (https://github.com/akopytov/sysbenc) を使用します 。sysbench と が インストールされていることを前提としています sysstat。
負荷をシミュレートする前に、これをターミナルで実行してみましょう vmstat。
cs ここでは、現在のコンテキスト スイッチの数が 35、割り込みの数 in が 19、r および b 両方が であること がわかります 0。現時点では他に実行中のタスクがないため、アイドル状態のシステムでのコンテキスト スイッチの数になります。
次に、マルチスレッド スケジューリング システムsysbenchのボトルネックを シミュレートするために実行してみましょう 。
$ sysbench --threads=10 --max-time=300 threads runvmstat 上記とは異なる出力が表示されるはずです 。
cs 列のコンテキストスイッチの数が、以前から 35 突然 139 10,000 回に増加していることがわかるはずです 。同時に、他のいくつかの指標にも注意してください。
r: 準備完了キューの長さに達しました8usandsy:とusのsyCPU 使用率の合計は100%、システム CPU 使用率は で84%、CPU が主にカーネルによって占有されていることを示します。in: 割り込みの数も増加しており10000、割り込み処理にも潜在的な問題があることがわかります。
これらの指標を組み合わせると、システムのレディ キューが長すぎる、つまり、CPU を実行して待機しているプロセスが多すぎるため、多数のコンテキスト スイッチが発生し、多数のコンテキスト スイッチが原因でエラーが発生していることがわかります。システムの CPU 使用率が増加します。
では、どのようなプロセスがこれらの問題を引き起こすのでしょうか?
分析を続けて 3 番目の端末で使用して、 pidstatCPU とプロセスのコンテキストの切り替えを確認しましょう。
# 1 means output interval is 1 second
# -w: output process switching index，
# -u: output CPU usage index
$ pidstat -w -u 1
08:06:33 UID PID %usr %system %guest %wait %CPU CPU Command
08:06:34 0 10488 30.00 100.00 0.00 0.00 100.00 0 sysbench
08:06:34 0 26326 0.00 1.00 0.00 0.00 1.00 0 kworker/u4:2
08:06:33 UID PID cswch/s nvcswch/s Command
08:06:34 0 8 11.00 0.00 rcu_sched
08:06:34 0 16 1.00 0.00 ksoftirqd/1
08:06:34 0 471 1.00 0.00 hv_balloon
08:06:34 0 1230 1.00 0.00 iscsid
08:06:34 0 4089 1.00 0.00 kworker/1:5
08:06:34 0 4333 1.00 0.00 kworker/0:3
08:06:34 0 10499 1.00 224.00 pidstat
08:06:34 0 26326 236.00 0.00 kworker/u4:2
08:06:34 1000 26784 223.00 0.00 sshd出力から 、CPU 使用率の増加は、実際に CPU 使用率が に達したことによって引き起こされている pidstat ことがわかります 。ただし、コンテキスト スイッチは、非自発的コンテキスト スイッチの頻度が最も高い カーネル スレッド や自発的コンテキスト スイッチの頻度が最も高いカーネル スレッド など 、他のプロセスから発生します。sysbench100%pidstatkworkersshd
注: デフォルトでは、
pidstatプロセスのコンテキスト スイッチのみが表示されます。-t実際のスレッドのコンテキスト スイッチを表示したい場合は、オプションを追加します。
割り込み
中断の数も多い理由を調べるには、 /proc/interrupts ファイルを確認してください。このファイルは、読み取り専用の割り込みの使用法を提供します。
# -d: Highlight the change area
$ watch -d cat /proc/interrupts
CPU0 CPU1
...
RES: 2450431 5279697 Rescheduling interrupts
...一定期間観察すると、最も速く変化するのは再スケジュール割り込み(RES、REScheduling Interrupt) であることがわかります。この割り込みタイプは、新しいタスクの実行をスケジュールするためにアイドル状態の CPU が起動されることを示します。したがって、ここでの割り込みの増加はタスク スケジューリングの問題が多すぎるためであり、これはコンテキスト スイッチの数に関する以前の分析結果と一致しています。
ここで最初の質問に戻りますが、1 秒あたり何回のコンテキスト スイッチが正常なのでしょうか?
この値は実際にはシステム自体の CPU パフォーマンスに依存します。私の意見では、システム内のコンテキスト スイッチの数が比較的安定している場合、数百から 1 万が正常であるはずです。ただし、コンテキスト スイッチの数が超過したり 10000、スイッチの数が急激に増加したりすると、パフォーマンスの問題が発生する可能性があります。
結論は
この時点で、コンテキストスイッチのタイプに基づいて特定の分析を実行できるはずです。
自発的なコンテキスト スイッチが多数あり、プロセスがリソースを待っていることを示し、I/O 飽和などの他の問題が発生する可能性があります。
多くの非自発的なコンテキスト スイッチが存在します。これは、プロセスが強制的にスケジュールされている、つまり CPU をめぐって競合していることを意味します。これは、CPU が実際にボトルネックを作成していることを意味します。
割り込み数の増加は、
/proc/interruptsCPU が割り込みハンドラーによって占有されていることを示します。 ファイルを表示して、特定の割り込みタイプを分析する必要があります 。
声明:この記事の内容はインターネットから得たものであり、著作権は元の著者に属します。作品に著作権上の問題がある場合は削除いたしますのでご連絡ください。
------------ 終了 ------------
公式アカウントをフォローして「グループを追加」と返信するとルールに従って技術交流グループに参加でき、「1024」と返信するとさらにコンテンツが閲覧できます。
さらに共有を表示するには、「元のテキストを読む」をクリックしてください。