web-dev-qa-db-ja.com

負荷平均は高いがCPU使用率とディスクI / Oが低い

サーバーの1つで奇妙な問題が発生しています。これは、1つの専用CPUコアを持つKVM= VPSにあります。

負荷が2.0前後に急上昇する場合があります: Load graph

ただし、CPU使用率はその期間中は実際には増加しません。これもiowaitが原因であることを除外します CPU usage graph

定期的に発生しているように見えます(たとえば、このグラフでは、約20〜25分ごとに発生しています)。 cronジョブの疑いがありますが、20分ごとに実行されるcronジョブはありません。また、cronジョブを無効にしてみましたが、それでもロードスパイクが発生します。

私は実際にSSHがサーバーに接続している間にこれが起こっているのを見ることができました... 1.88の負荷がありましたが、CPUは94%アイドルであり、0%iowaitがありました(これが原因であると私が予想したものです)

<code>top</code> output<code>htop</code> output

これが発生すると、ディスクI/Oが大量に発生するようには見えません。

私は困惑しています。何か案は?

5
Daniel Lo Nigro

それで私はこれを解決しました...それはサーバー(Netdata)を監視するために使用していたソフトウェアが原因であることがわかりました。

Linuxは5秒ごとに負荷平均を更新します。実際、実際には5秒ごとに1つの「ティック」に加えて更新されます。

sched/loadavg.h

#define LOAD_FREQ   (5*HZ+1) /* 5 sec intervals */

sched/loadavg.c

 * The global load average is an exponentially decaying average of nr_running +
 * nr_uninterruptible.
 *
 * Once every LOAD_FREQ:
 *
 *   nr_active = 0;
 *   for_each_possible_cpu(cpu)
 *  nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
 *
 *   avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)

HZはカーネルタイマーの頻度で、カーネルのコンパイル時に定義されます。私のシステムでは250

% grep "CONFIG_HZ=" /boot/config-$(uname -r)
CONFIG_HZ=250

つまり、5.004秒(5 + 1/250)ごとに、Linuxは負荷平均を計算します。アクティブに実行されているプロセスの数と、中断できない待機(ディスクIOの待機など)状態にあるプロセスの数をチェックし、それを使用して負荷平均を計算し、時間の経過とともに指数関数的に平滑化します。

毎秒、一連のサブプロセスを開始するプロセスがあるとします。たとえば、一部のアプリからデータを収集するNetdata。通常、プロセスは非常に高速で、負荷平均チェックと重複しないため、すべて正常です。ただし、1251秒(5.004 * 250)ごとに、負荷平均更新間隔は1秒の正確な倍数になります(つまり、1251は5.004と1の最小公倍数です)。 1251秒は20.85分です。これは、負荷平均の増加が見られたまさにその間隔です。 Linuxは、20.85分ごとに、いくつかのプロセスが開始されて実行待ちの正確な時間に負荷平均をチェックしていると私は推測しています。

これを確認するには、netdataを無効にし、手動で負荷平均を監視します。

while true; do uptime; sleep 5; done

1.5時間後、anyのようなスパイクは見られませんでした。スパイクのみは、Netdataの実行中に発生します。

だから...結局のところ...私が負荷を監視するために使用していたアプリが、その原因となったものでした。皮肉。彼は他人を死から救うことができたが、自分自身を救うことはできなかった。

間隔は異なりますが、過去に他の人々が同様の問題に遭遇したことがわかりました。次の投稿は非常に役に立ちました。

こちらのNetdata開発者に報告しました: https://github.com/netdata/netdata/issues/5234 。結局、これをバグと呼ぶかどうかはわかりませんが、おそらくnetdataがジッターを実装して、1秒ごとに正確にチェックを実行しない可能性があります。

5
Daniel Lo Nigro