Linux でのパフォーマンスの問題のトラブルシューティングに関しては、uptime、vmstat などのさまざまなコマンド出力の基本を知ることが非常に重要です。この投稿では、CPU 使用率の観点から、負荷平均と実行キュー/ブロックされたキューを理解しようとします。まず、負荷平均とは何かを理解しましょう:
負荷平均は、1、5、および 15 分間の平均で、実行キュー (状態 R) またはディスク I/O を待機中 (状態 D) にあるジョブの数です。 uptime/top コマンドからの出力例:
# uptime 11:49:14 up 25 days, 5:56, 68 users, load average: 0.03, 0.13, 0.47
# top -b -n 1 top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached
経験則は次のとおりです。
- シングル コア システム – 負荷平均が 1.00 の場合、システムが完全に使用されていることを意味し、さらに多くのタスクが受信される場合、キューに入れられて実行を待機します。
- シングル コア システム – 負荷平均が 2.00 の場合、システムは既に使用されており、一部のタスクは既にキューに入れられて実行を待機していることを意味します。
- マルチコア システム (4 コア) – 平均負荷が 1.00 の場合、システムは CPU 能力の 1/4 を使用しており、1 つのタスクがアクティブに実行されており、まだ 3 つのコアが「アイドル」段階にあることを意味します。
- マルチコア システム (4 コア) – 負荷平均が 4.00 の場合、システムが 4 つのコアすべてを使用していることを意味し、システムが完全に使用されていることを示します。
上記の場合、まだヘッドルームが残っていますか? – 通常はいいえ – 負荷平均がシステムのコア数に近い場合 – OS を見直して、実際のボトルネックやチューニングの欠落がないか、または OS が APP/DB タスクを処理するために適切にスケーリングされていないかどうかを確認する必要があります。
アクティブ OS での負荷平均値はどのように計算されていますか? – このためには、vmstat コマンドで利用可能な実行キューを見つける必要があります:
アイドル システム (8 コア システム)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 0 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 0 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 0 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
アクティブ システム (8 コア システム)
# vmstat 1 6 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0 7 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0 2 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0 6 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0 1 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0 8 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0
上記の出力は例です。最初の出力は、現在の実行キュー (r) が 0 であることを示しています。アクティブなシステムでは、実行キューが 6 プローブで 1 から 8 にジャンプします。
実行キューとは正確には何ですか?
ランキュー :アクティブ (実行中) およびキューに入れられたプロセスの数。
2 番目の例では、システムがアクティブであるとき、8 の実行キューが表示されます。これは、8 コアで実行する必要があるシステムの最大上限です。もちろん、実行キューは 36 や 101 などの値を示す場合があります。最初の 36 に 36 コアがあり、2 番目の 101 に 101 を超えるコアがある場合、それらはまったく問題ありません。
実行キューの列は、常にシステムにインストールされているコアの数よりも小さい/同じである必要があります。もちろん、100 の実行キューは、8 コアのみのシステムで表示できます。これは、8 つのプロセスが CPU によってアクティブに処理され、残りの 92 がキューに入れられていることを意味します。そして実行を待っています。実行キューがインストールされている CPU コアを上回っている場合は、APP/DB のパフォーマンスのチェックとチューニングの欠落に関して調査を行う必要があります。または、そのような実行キュー/負荷を処理するためにシステムが適切にスケールアップされていないことを示している可能性があります。
負荷平均の実行キューがインストールされているコアの数を下回るように維持する必要があるのと同様に、この値を最大しきい値を下回るように維持しないと、OS がディスク/ネットワークでハートビート監視をキューに入れるだけなので、(システムが HA 対応の場合) スローダウン/ハングまたはエビクションのケースが発生します。他のタスクを提供するのに忙しいので、層。負荷平均と実行キューが高いと、突然クラッシュ/ハングアップするケースが発生します。サードパーティの監視ツールを介して両方の値を積極的に監視し、実行キュー/負荷平均が実際の CPU リソースの 70% 以上を使用している場合にアラートを出す価値があります。
Load Average によっても取得されている 2 番目の重要な列は、ブロックされた状態のプロセスを説明する vmstat の「b」状態です。これは、状態 D のプロセス (バックエンド IO が終了するのを待っている - 通常はストレージ アクティビティ) として簡単に解釈できます。負荷平均が高く、アクティブに実行されているプロセスがなく、vmstat が異常な「b」状態値を示している場合は、SAN のパフォーマンスを確認するか、ISCSI/NFS/NIC/HBA などの OS コンポーネントを確認する必要があります。 Linux では深刻な閉塞状態。たとえば、NFS サーバーは CPU レベルでビジーであり、すべてのクライアント ( Linux ) プロセス/タスクが状態 d ( b ) でキューに入れられ、「キューイング」につながり、その後大量の実行キューが解放される可能性があります。後でバックエンド IO が完了するのを待っていると、再び実行中になり、大規模な実行キューが発生する可能性があります。これにより、ハング/パニック状態が発生したり、後でエビクション ケースが発生したりする可能性があります。
平均負荷が高いため、ネットワーク スループットと TCP/UDP トラフィックも影響を受けます。これは、システムが、着信/発信接続の確認以外の他のタスクの処理で忙しくなり、NFS/ISCSI 経由の着信ネットワーク IO トラフィックを優先するためです。場合によっては、TOP が表示されることがあります。 %CPU 値を 100 より大きくすることはまったく問題ありません。これは、Linux のデフォルトで TOP コマンドがシングル コア操作を示しているため、マルチコア セットアップでは %CPU 値が 100% より大きくなる可能性があるためです。たとえば、PID が 4 つのコアを完全に使用する場合、%CPU 値は 400 と表示されます
# top top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1438 java 20 0 945m 4220 2528 S 400.5 0.0 56:31.95 java <---
%CPU に関する情報:
## %CPU -- CPU Usage The task's share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if a process is multi-threaded and top is not operating in Threads mode, amounts greater than 100% may be reported. You toggle Threads mode with the 'H' interactive command. ##
実行中/ブロックされているプロセスをすばやく一覧表示するには、以下の ps コマンドを使用します:
# ps r -Af
プロセス スレッドを一覧表示して、親 PID によって生成された一部のスレッドが CPU スパイクの問題を引き起こしていないかどうかを確認するには、次を実行します。
# ps -e -To pid,ppid,state,pcpu,command
または
# ps -elfL
また、OS CPU がアクティブにサービスを提供しているかどうかを確認するには、ユーザー ( US ) スペースを以下のコマンド例で使用します。
# sar -P ALL 1 Linux 3.8.13-118.13.3.el6uek.x86_64 (lgeeklab) 01/08/2017 _x86_64_ (8 CPU) 02:40:38 PM CPU %user %nice %system %iowait %steal %idle 02:40:39 PM all 12.62 0.00 0.12 6.88 0.00 80.38 02:40:39 PM 0 0.00 0.00 0.00 54.55 0.00 45.45 02:40:39 PM 1 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 2 0.99 0.00 0.00 0.00 0.00 99.01 02:40:39 PM 3 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 4 100.00 0.00 0.00 0.00 0.00 0.00 02:40:39 PM 5 0.98 0.00 0.98 0.00 0.00 98.04 02:40:39 PM 6 0.00 0.00 0.00 0.00 0.00 100.00 02:40:39 PM 7 0.00 0.00 0.00 0.00 0.00 100.00 Average: CPU %user %nice %system %iowait %steal %idle Average: all 12.63 0.00 0.13 6.00 0.00 81.24 Average: 0 0.00 0.00 0.00 45.23 0.00 54.77 Average: 1 0.50 0.00 0.00 3.00 0.00 96.50 Average: 2 0.50 0.00 0.00 0.00 0.00 99.50 Average: 3 0.00 0.00 0.00 0.50 0.00 99.50 Average: 4 100.00 0.00 0.00 0.00 0.00 0.00 Average: 5 0.50 0.00 0.50 0.00 0.00 99.00 Average: 6 0.00 0.00 0.00 0.00 0.00 100.00 Average: 7 0.00 0.00 0.00 0.00 0.00 100.00
# mpstat -P ALL Linux 3.8.13-118.13.3.el6uek.x86_64 (geeklab) 01/08/2017 _x86_64_ (8 CPU) 02:41:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:41:26 PM all 0.79 0.00 0.10 1.18 0.00 0.02 0.00 0.00 97.92 02:41:26 PM 0 0.94 0.00 0.14 2.84 0.00 0.02 0.00 0.00 96.06 02:41:26 PM 1 0.94 0.00 0.14 2.70 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 2 0.93 0.00 0.14 1.13 0.00 0.03 0.00 0.00 97.77 02:41:26 PM 3 0.94 0.00 0.13 2.71 0.00 0.02 0.00 0.00 96.20 02:41:26 PM 4 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.28 02:41:26 PM 5 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 6 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27 02:41:26 PM 7 0.64 0.00 0.05 0.01 0.00 0.01 0.00 0.00 99.29
さらに、以下の TOP コマンド スイッチを使用して、PID スレッド情報と、前回 PID を提供したコアを取得できます:
TOP にスレッドを表示するには:
# top -H
前回実行した PID を提供したコアを表示するには:
# top
次に「F」を押します 」を押して「J」を押します ' を入力して Enter キーを押すと、'P' である以下の出力が得られます ' 行は最後に使用された CPU になります。
Tasks: 1045 total, 2 running, 1043 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 93.6%id, 5.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16159656k total, 15349888k used, 809768k free, 597960k buffers Swap: 8232956k total, 218784k used, 8014172k free, 9840192k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 10428 root 20 0 15228 2228 1724 S 0.7 0.0 0:26.86 2 top 10838 oracle 20 0 4921m 585m 5708 S 0.7 3.7 137:11.13 3 mysqld 15360 root 20 0 15888 2792 1724 R 0.7 0.0 0:00.55 6 top 528 root 20 0 0 0 0 S 0.3 0.0 76:39.23 0 jbd2/dm-0-8 9003 root 20 0 0 0 0 S 0.3 0.0 8:49.33 2 jbd2/dm-3-8 10815 oracle 20 0 4921m 585m 5708 S 0.3 3.7 13:35.18 1 mysqld 14902 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 19:54.77 3 java 15021 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 20:09.19 1 java 15094 oracle 20 0 9431m 2.4g 28m S 0.3 15.5 6:54.88 3 java 32045 enduser 20 0 15228 2220 1724 S 0.3 0.0 9:32.73 5 top 32278 root 20 0 15228 2212 1724 S 0.3 0.0 9:32.96 1 top
よくある質問
8 コア システムで負荷平均が同じ値の 8 つの実行プロセスのように、システムを上限で実行する必要がありますか?
答え - いいえ
システムは適切にスケールアップし、可能性の 70% を超えないようにする必要があります。そのため、新しいタスクを実行するための余裕があります。これは、HA 対応のサーバーや、ハイエンドが存在するシステムにとって特に重要です。アクティブな OS によって誤ってキューに入れられる可能性がある IO/ネットワーク コンポーネント。この詳細なチェックについては、APP/DB チームが実行して、OS で何がアクティブに実行されているかを正確に確認する必要があります。
APP/DB タスクだけが高い実行キュー/負荷平均を引き起こしていますか
答え - いいえ
一部の OS タスクでは、実行キューまたは負荷平均が高くなることがありますが、これらは非常にまれなケースです。この場合、 top コマンドは、 US /SY / NI / ID / WA / HI / SI / ST 値を監視し、カーネルレベルでプロセッサ時間がどれだけ費やされるかを示す SY ( System ) セクションに焦点を当てるのに役立ちます。実際の US (ユーザー) 使用率よりも常に低く、たとえば SY が CPU の 20 ～ 30% を使用していないことを確認してください (CPU の設定と実際のケースによって異なります)。
たとえば、高 IO/ネットワーク操作中またはメモリ不足の場合に高い %SY が表示される場合があります。プロセスの例:kjorunald.高い %SY は、システムの負荷が高い場合にも表示される場合があります。たとえば、APP/DB タスクが原因で実行キューが高い場合やキューがブロックされている場合などです。ほとんどの場合、%SY は約 20 ～ 30% で、%US は
高い %SY は、常にカーネルまたは OS の問題があることを意味するわけではありません。たとえば、アプリケーション/データベース コードが原因で、特定のカーネル関数の周りで多くのシステム コールが行われる可能性があります。これをさらにデバッグするには、strace または perf を使用する必要があります。特定の PID 相互作用を検証します。
シングル コアは一度に 1 つのプロセス タスクしか処理できないということですか?
答え - はい/いいえ
CPU はマルチタスク用に設計されています - シングル コア システムでもユーザーは複数のタスクを実行し、複数のアプリケーションを起動できます。実行されます (これは 1 秒間に数回発生する可能性があります)。
最新のシステムは、マルチコア/マルチスレッド機能を利用して、この切り替えの影響を目立たなくします。したがって、エンタープライズ システムでは、ユーザーはアプリケーションが実際のマルチタスク操作を実現する小さなスレッドを作成できるマルチコア セットアップを使用します (各コアは異なるタスクを処理できます)。システムの平均負荷が低く、タスク キューが少ない - たとえば、デュアル コア システムは、アプリケーション/スレッド/タスクを 2 つの個別のコアに分割できるため、シングル コア システムと比較してコアがタスクの半分だけを切り替えることができるため、システム パフォーマンスへの影響がはるかに少なくなります。