CPUもディスクも使いすぎないにもかかわらず、負荷が高い理由
topから次の出力を取得しています：
Cpu(s): 43.8%us, 32.5%sy, 4.8%ni, 2.0%id, 15.6%wa, 0.2%hi, 1.2%si, 0.0%st
Mem: 16331504k total, 15759412k used, 572092k free, 4575980k buffers
Swap: 4194296k total, 260644k used, 3933652k free, 1588044k cached
iostat -xk 6からの出力は次のようになります。
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 360.20 86.20 153.40 1133.60 2054.40 26.61 1.51 6.27 0.77 18.38
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 22.60 198.80 17.40 31.60 265.60 921.60 48.46 0.18 3.70 1.67 8.20
sdc 16.80 218.20 22.20 23.40 261.60 966.40 53.86 0.21 4.56 1.49 6.78
上記に基づいて、何かをオーバーロードする必要があるように見えます。しかし、何ですか？
ご質問
- ハードディスクでもCPUでもない場合はどうなりますか？
- CPU時間の15.6％が待機に費やされているようです。正確には何を待っているのでしょうか？
明確にするために、負荷はCPUに直接結び付けられていません。これは、負荷に関する最も一般的な誤解の1つです。あなたがディスクについて言及しているという事実は、あなたがこれを認識していることを認めているようですが、私は、他の人がそうではないと信じていることを示すコメントを見ているので、それを言及したかっただけです。
負荷は、システムリソースで待機しているプロセスの数として定義されます。これは通常、CPU、ディスク、またはネットワークですが、実際にはハードウェアであれば何でもかまいません。
「プロセス」も必ずしも完全なプロセスではありません。スレッドは「軽量プロセス」として定義され、待機している各スレッドは負荷カウントを増やします。
問題のあるプロセスを特定するには：
top -Hを実行します（-Hはスレッドの表示を有効にします）
キーボードショートカットはバージョンによって異なります。
新しいトップ（3.3以降）：
押す f フィールドオプションを表示します。
矢印キーを使用してS = Process Statusに移動し、 s。
押す q メインページに戻ります。
押す Shift + R ソートを逆にします。
古いトップ（3.3より前）の場合：
押す Shift+o 並べ替えオプションを表示します。
その後 w プロセスのステータスで並べ替えます。
その後 Enter メインページに戻ります。
その後 Shift + R ソートを逆にします。
次に、S列で、DまたはRが含まれているプロセスを探します（現在、これらは最上部にあるはずです）。これらは、システム負荷の原因となるプロセスになります。
プロセスがDを示している場合、それは「中断できないスリープ」を意味します。通常、これはプロセスがI/O（ディスク、ネットワークなど）で待機しているときに発生します。
プロセスがRを示している場合、それは単に通常の計算を行っていることを意味します。
これらのプロセスが実行していることの詳細を見つけるには：
新しいトップ（3.3以降）：
押す f フィールドオプションを表示します。
矢印キーを使用してWCHAN = Sleeping in Functionに移動し、 d それを有効にします。
その後 q メインページに戻ります。
古いトップ（3.3より前）の場合：
押す f その後 yWCHANフィールドを有効にします。
システムに必要なカーネルオプションがあり、wchanファイルがシステムに存在する場合（どこにあるか、何と呼ばれるか忘れています）の場合、WCHANフィールドにどのカーネルが表示されますプロセスが現在実行している関数（フィールドがすべてについて-または?を表示しているだけの場合、サポートはありません）。
ここに少しのグーグルがあり、あなたはあなたの道にいるはずです。
Wchanサポートがない場合は、いつでもプロセスでstraceを試して、プロセスが何をしているかを調べることができますが、それは難しい方法です。
ジョブのコンパイルやループでのプロセスの失敗など、寿命が短いプロセスは、topやiostatなどの監視ツールでは見えないことがよくあります。
このような場合、Linux Audit Frameworkが役立ちます
犯人、たとえば失敗のループ
while :; do gcc /dev/zero ; done >/dev/null 2>&1
Auditd/auditctlを使用するには：
apt-get install auditd
auditctl -a task,always
ausearch -i -sc execve
盗まれた すべてのプロセスの起動を記録
NFSマウントが切断されたという状況にあり、残念ながらミスしてソフトマウントオプションを使用しなかったため、監視、lsof、さらにはbashセッションなど、多くのプロセスがLinuxサーバーで停止しました。
壊れたマウントをアンマウントした後、システムは過負荷に見えました。
top - 00:03:48 up 15 days, 14:56, 3 users, load average: 29, 21, 20
これはひどいように見えましたが、CPU使用率が15％未満で、ディスクI/Oがありません。 psを通過するようにいくつかのアドバイスをもらいましたが、プロセスがほとんどスリープしているように見えたため、これは役に立ちませんでした。
次にman ps睡眠のために私の夜を救いました。調査の結果、後で確認する必要のある非常に重要なSTATUSフラグが見つかりましたstuckプロセス。
実行：
ps -e v
sTAT列にDまたはSLがあるプロセスを探します。これらはゾンビプロセスのようでしたが、Zゾンビとして識別されませんでした。
D-主にディスク（I/O）アクティビティを意味しますが、ps -e v数回、またiostat 3とアクティビティが表示されない、これはスタックI/Oであることを示しています。
SL-これは、そのプロセスのメモリ内にロックされたページがあることを意味します。したがって、このプロセスがこのように動作してはならないことを識別できた場合、変更なしでより長い期間継続すると、次の候補となります。
調査後、私は1人ずつ殺し、システムの負荷平均は正常になりました。