クラウドインスタンスで高いソフトウェア停止率の根本原因を見つける

クラウドインスタンスで高いソフトウェア停止率の根本原因を見つける

topを使用してスキャンするときに奇妙なロードパターンを示すクラウドインスタンスがあります。

top - 21:39:28 up 456 days,  8:39,  2 users,  load average: 1.44, 1.19, 1.10
Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie             
%Cpu(s):  5.2 us,  0.7 sy,  0.0 ni, 57.5 id,  1.7 wa,  0.0 hi, 34.9 si,  0.0 st
KiB Mem : 16134024 total,   160756 free,  3009108 used, 12964160 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 12620768 avail Mem

上記のタイトルからわかるように、SI(ソフトウェアの中断)比率は35%です。

ソフトウェア割り込みを確認すると、60秒間約20Kが増加した/proc/interruptsため、犯人である可能性が高いです。Rescheduling interrupts

今私が閉じ込められているのは、どのプロセスがこのレベルの再配置を引き起こしたのかを理解しようとすることです。

何をすべきか調べる根本原因実行中のサービスに触れないでください。

追加情報:

  • 2つのvCPU、16GメモリKVMベースのクラウドインスタンスのAWSベースのDebian 9(ストレッチ)。
  • Linux ip-10-0-0-138 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
  • このインスタンスは他のサービスのLBを持って実行されますnginxvarnish

編集する: 根本原因を特定する前に、他のオペレータがインスタンスを再起動しました。再起動後も同じ負荷に対して%SI1.5%を超えず、Rescheduling interrupts60秒以内に前の値の3分の1未満に低下しました。

ベストアンサー1

60秒で約20Kです。

毎秒400個未満で、多くのコアが眠り、定期的な作業を実行するシステムでは、これらの作業はおおよそ定期的に目覚めます。

ただし、2コア(CPUコア1つとハイパースレッド2つ以上)サーバーでは、ライブオーディオシステム(ジャックなど)を実行しないことがあります。また、休止状態に切り替えることができるコアは1つだけです。

2つのvCPU、16GメモリKVMベースのクラウドインスタンスのAWSベースのDebian 9(ストレッチ)。

ああ!

実際の割り込みハンドラソースコードのコメントの比較カーネルバージョンから:

/*
 * KVM uses this interrupt to force a cpu out of guest mode
 */

つまり、仮想マシンやソフトウェアに問題がない可能性があります。 KVMハイパーバイザーは、他のタスクを実行するために現在仮想マシンで使用されているCPUコアの1つを切り替えようとするだけです。

おそらく、これは負荷が軽く、AmazonはCPUコアの全体的なパフォーマンスを継続的に期待していないため、より多くのユーザーに同じCPU時間を販売できると考えているからです。

実験してみてください:それを実行し、stress -c 2高い負荷(疑いなくペイロードのパフォーマンスに悪影響を及ぼす)がスケジューリング割り込みの数を大幅に減らすことを確認してください。

しかし、実際に得られる効果は非常に小さいです。 AWS は、無駄なシステムに高いパフォーマンスを補償すると思います。したがって、問題は、これらのスケジュール調整の中断が許容できないかどうかです。これは、主に両方のCPUの半分未満のリソースを使用する場合に発生する可能性があります。スレッド。

おすすめ記事