我有一个云实例，在使用 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%。
检查/proc/interrupts软件中断给了我可能的罪魁祸首，因为Rescheduling interrupts它在 60 秒的时间内跳跃了约 20K。
我现在陷入困境的是试图找出哪些流程导致了这种程度的重新安排。
怎么办我弄清楚根本原因不触及正在运行的服务？
附加信息：
- AWS 上基于 2 个 vCPU、16G mem KVM 的云实例上的 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- 该实例具有
nginx并varnish作为其他服务的 LB 运行。
编辑：
在我找出根本原因之前，另一位操作员重新启动了该实例。重新启动后，对于相同的负载， 并%SI没有超过 1.5%，并且Rescheduling interrupts在 60 秒的时间内下降到了之前值的三分之一以下。
答案1
60 秒内约 20K。
数量并不多；它每秒不到 400 个，并且符合我对多核处于睡眠状态并且有周期性工作要做的机器的预期数量级，因此这些会定期被唤醒。
但是，您可能没有在 2 核（可能更多：1 个 CPU 核和 2 个超线程）服务器上运行现场音频系统（如 jack）。而且，你只有一个可以休眠的核心。
AWS 上基于 2 个 vCPU、16G mem KVM 的云实例上的 Debian 9（延伸）。
啊哈！
对比实际中断处理程序源码中的注释在你的内核版本中:
/* * KVM uses this interrupt to force a cpu out of guest mode */
换句话说，您的虚拟机或软件可能根本没有任何问题，只是 KVM 管理程序想要切换虚拟机当前使用的 CPU 核心之一来执行其他操作。
据推测，这是因为您的负载很轻，并且亚马逊认为他们可以将相同的 CPU 时间出售给更多用户，因为您不会期望持续拥有的 CPU 核心的全部性能。
做一个实验：运行stress -c 2并查看高负载（无疑对有效负载性能不利）是否会显着减少重新安排中断计数。
然而，你将得到的实际效果很小：我怀疑 aws 会以更高的性能奖励浪费的机器，因此问题是这些重新安排中断是否不可接受 – 它们可能主要发生在你只利用较少的资源时超过两个 CPU 线程的一半。