背景：本地机器部署 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分钟负载：系统在过去1分钟内运行队列中的平均进程数量。
  2. 5分钟负载：系统在过去5分钟内运行队列中的平均进程数量。
  3. 15分钟负载：系统在过去15分钟内运行队列中的平均进程数量。

负载的含义是在系统中等待运行的进程数。如果这个数字高于系统的逻辑CPU数量，表明系统负载很高，意味着有许多进程正在等待处理器资源。这可能会导致系统变得缓慢或不响应，具体取决于负载的高低程度以及系统的配置和性能。

在理想情况下，负载应该保持在系统的逻辑CPU数量范围内，这样系统的性能就能够得到最优化。如果负载持续高于CPU数量，可能需要进一步分析系统中的进程，找出导致负载高的原因，并采取相应的措施来调整系统资源分配或优化进程的运行方式。

分析负载 mpstat

mpstat 命令用于报告单个或多个处理器的多个信息，包括平均负载、CPU利用率、中断和上下文切换等。在 sysstat 包中，mpstat 是非常有用的工具，可以用来分析系统的负载情况。下面是使用 mpstat 进行负载分析的步骤：

  1. 安装 sysstat： 如果您的系统上没有安装 sysstat，可以使用适合您系统的包管理工具进行安装。

  2. 运行 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

  3. 分析输出： mpstat 的输出包括了每个 CPU 的利用率，以及系统的平均负载。特别关注平均负载以及每个 CPU 的利用率，可以帮助您了解系统的负载情况。如果负载较高，可以进一步分析是哪些进程导致的，以及是否存在性能瓶颈。

  4. 结合其他工具： 除了 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