背景：本地机器部署 windows 版本的业务系统，cpu 资源占用 5% 左右。vmware安装的 centos8 中部署 linux 版本业务系统，资源占用异常。
问题描述
- 宿主机：win10 企业版
- vmware：17.5
- 虚拟机：centos8
虚拟机资源分配为4C8GB，启动业务系统。业务系统部署在虚拟机Linux系统中，虚拟机内部 top 命令观察系统资源占用，cpu 占用并不高，外层 windows 系统，任务管理器观察到的CPU资源占用很高，查看进程发现，vmware 进程占用CPU资源很高。
+—————————+ | Windows | | | | +——————–+ | | | VMware | | | | Program | | | +——————–+ | | | +—————————+
知识点
此问题的排查，并不顺利，由于导火索并不是业务系统本身，而是虚拟机本身的问题。如何将思路从常规的业务代码转移到系统负载，再从负载数据的异常，定位到软中断，最后来到关键点，什么东西会影响 Vmware 软中断的工作效率？本文将先科普各个知识点，最后给出解决方案。
hyper-v
Windows操作系统的虚拟化技术经历了一次重大变革。在微软首次发布WSL时，启用Hyper-V服务会导致无法同时使用VMware虚拟机。直到后续版本，VMware才能与Hyper-V服务兼容。
系统负载
在Linux系统中，“负载”（load）是指系统中正在运行或等待执行的进程的数量。负载通常由三个数字表示，分别是1分钟、5分钟和15分钟内运行队列中的平均进程数量。这些数字可以通过运行"uptime"命令或"top"命令来查看。
具体来说，这三个数字分别代表：
- 1分钟负载：系统在过去1分钟内运行队列中的平均进程数量。
- 5分钟负载：系统在过去5分钟内运行队列中的平均进程数量。
- 15分钟负载：系统在过去15分钟内运行队列中的平均进程数量。
负载的含义是在系统中等待运行的进程数。如果这个数字高于系统的逻辑CPU数量，表明系统负载很高，意味着有许多进程正在等待处理器资源。这可能会导致系统变得缓慢或不响应，具体取决于负载的高低程度以及系统的配置和性能。
在理想情况下，负载应该保持在系统的逻辑CPU数量范围内，这样系统的性能就能够得到最优化。如果负载持续高于CPU数量，可能需要进一步分析系统中的进程，找出导致负载高的原因，并采取相应的措施来调整系统资源分配或优化进程的运行方式。
分析负载 mpstat
mpstat 命令用于报告单个或多个处理器的多个信息，包括平均负载、CPU利用率、中断和上下文切换等。在 sysstat 包中，mpstat 是非常有用的工具，可以用来分析系统的负载情况。下面是使用 mpstat 进行负载分析的步骤：
-
安装 sysstat： 如果您的系统上没有安装
sysstat，可以使用适合您系统的包管理工具进行安装。 -
运行 mpstat： 使用
mpstat命令查看 CPU 的使用情况和负载。默认情况下，mpstat每秒钟显示一次 CPU 使用情况的平均值。您可以通过指定时间间隔来调整输出频率。例如，要以每秒钟一次的频率运行mpstat，可以使用以下命令：mpstat -P ALL 2，irq表示占用资源占用01:32:33 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 01:32:35 PM all 0.00 0.00 0.26 0.00 3.73 0.26 0.00 0.00 0.00 95.76 01:32:35 PM 0 0.00 0.00 0.51 0.00 3.57 0.00 0.00 0.00 0.00 95.92 01:32:35 PM 1 0.00 0.00 0.00 0.00 3.59 0.51 0.00 0.00 0.00 95.90 01:32:35 PM 2 0.00 0.00 0.00 0.00 4.15 0.00 0.00 0.00 0.00 95.85 01:32:35 PM 3 0.00 0.00 0.52 0.00 3.61 0.52 0.00 0.00 0.00 95.36 -
分析输出：
mpstat的输出包括了每个 CPU 的利用率，以及系统的平均负载。特别关注平均负载以及每个 CPU 的利用率，可以帮助您了解系统的负载情况。如果负载较高，可以进一步分析是哪些进程导致的，以及是否存在性能瓶颈。 -
结合其他工具： 除了
mpstat，还可以使用sar、pidstat、iostat等工具来综合分析系统性能。通过结合多种工具的输出，可以更全面地了解系统的负载情况，并找出性能问题的根源。
中断
此处不展开讲解内容太多， 推荐: 《面向应用开发者的系统指南》CPU篇之软中断
频繁的触发软中断，也会体现在系统负载中。
问题排查
考虑到仅从CPU角度分析无法定位问题，我们是否应该开始怀疑系统是否出现了异常？可能是Linux操作系统的负载过高，导致VMware占用了过多的CPU资源。通过使用mpstat分析本地虚拟机，我们发现irq占用异常，单核接近25%，而在正常情况下，启动业务进程空跑时，irq占比应该约为5%。
在组内同事的开发环境中，他的CentOS 7部署在VMware上，资源占用显示正常。另一方面，在上海的开发环境中，虽然也是VMware，但我们无法直接观察宿主机的CPU资源情况。这时，我们面临着多个变量：VMware虚拟机、Linux操作系统和GCC版本。
转而分析测试环境，深圳的测试环境部署在物理机上，运行着低版本GCC编译的服务，而且在CentOS 8上运行。有趣的是，在深圳环境中，irq占用都是正常的。
为了排查GCC版本引入的问题，我们将使用高版本GCC编译的程序部署到深圳环境进行测试，结果显示也都是正常的。
问题似乎变得更加明朗，我们开始怀疑操作系统是否存在问题。毕竟，CentOS 8已经不再受到官方支持。但即便重新部署了纯净的CentOS 7和CentOS 8，问题依然存在。
此时，我们开始怀疑唯一的不确定因素，即VMware虚拟机软件。突然间，灵光一现，我们想到了Hyper-V技术。是否之前启用了Hyper-V，但没有彻底关闭，从而导致了这个问题？毕竟，软中断也是通过虚拟机软件来实现的。不同的虚拟机虚拟技术是否存在BUG？这些问题值得深入思考和调查。
结论
根据微软官方的手册，我们完全关闭了本机的Hyper-V服务后，发现VMware在宿主机上恢复了正常。至此，问题终于迎刃而解。正如一开始所述，这段经历曲折而艰辛，需要综合性的分析和判断。这也是我们首次排查问题，定位到了虚拟机这一层面。
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
bcdedit /set hypervisorlaunchtype off