记一次问题分析：spdk轮询模式CPU占用率很低？

原创张洋 2026-02-11

近日遇到一个问题，zStorage 的 FrontEnd 进程启动后，CPU 占用率很低，不到 80%。按正常情况来说，FrontEnd（以下简称 FE）绑定到 8 个 CPU 核心上，并以轮询模式运行，应该占用 800% 的 CPU。

PART1：排查过程

首先能想到的是，FE 是否启动了 8 个轮询线程，是否工作在轮询模式下。通过检查配置文件，确认 FE 绑定了 8 个 CPU 核心，并且 8 个轮询线程也已正常启动，并运行在不同的 CPU 核心上。

如图所示，FE 一共启动了 8 个 Reactor，每个 Reactor 是一个系统线程，绑定于指定的 CPU 核心上。例如，reactor_24 绑定于 24 号 CPU 核心，reactor_26 绑定于 26 号 CPU 核心。但是，每个 Reactor 仅占用了 8.3% 的 CPU，这非常反常。

那么，会不会是因为新修改的代码调用了阻塞性的函数，例如 read、sleep 等呢？使用 strace 抓取的信息如下：

通过对比正常节点 FE 的 strace 信息和异常节点 FE 的信息，发现二者没有任何区别。并且，从修改的代码来看，也并未引入阻塞性的操作。因此，继续转向其他排查思路。

针对 Reactor_24 运行在 24 号核心上，24 号核心到底每秒钟执行了多少时钟周期呢？（图中用的是 72 号核心，由于当时没有截图，这里是重新补的图。）

如图所示，每秒有 2.4G 个时钟周期。如果每秒跑 2.4G 个周期，这个 CPU 核应该是已经跑满到 100% 了。那么，为什么 FE 显示只占用了 8% 的 CPU 呢？难道是显示错误？

接着用 perf stat -C 72 -p 3324 -e cycles sleep 1，指定 FE 的进程 ID 再抓一次，确实显示时钟周期很少。FE 并未执行到 2.4G 个周期，CPU 占用率只有 8%，这也就说得通了。

使用 spdk_top 工具查看 Reactor 的转速，每秒大概 20 万次，而正常情况应该在 200 万次左右，仅为 10%。

再次打开 top 工具，按下 1 键，显示了每个 CPU 核心的使用率。可见，24 号核心的使用率确实是 100%。到底是被谁占用了呢？

好吧，先避开这些异常的 CPU 核心，将 FE 绑定到其他的 CPU 核心上，然后重新启动。通过 htop 工具查看，这下 FE 的 CPU 占用正常了，8 个核心都是 100%。

那么这些异常的 CPU 是被谁占用的呢？再看一眼之前的 top 信息，确实总的 CPU 占用率达到了 38.3%。这条服务器上一共有 96 个核心，那么相当于有 36 个 CPU 核心是 100% 的使用率。但是从进程占用率来看，远远达不到。

事出反常必有妖。难道是中毒了，被挖矿了？

PART2：拓展分析

网上搜了下挖矿病毒的相关资料，找到了一个名为 libprocesshider.so 的东西。从名字看就不是什么好东西，进程隐藏，谁没事隐藏进程干啥。在我们的机器上果然是有这么一个文件。这个病毒难道就是利用这个动态库达到隐藏自身，在后台悄悄占用 CPU 资源挖矿的目的？

那么这个动态库是怎么运行起来的呢？查看 /etc/ld.so.preload，发现正是 /usr/local/lib/libprocesshider.so。有了这个配置以后，在启动一个进程的时候，就可以预先将 libprocesshider.so 加载到进程中。

那么，尝试删除 /etc/ld.so.preload 试试，top 现在无法再访问 /etc/ld.so.preload，隐藏的占用 CPU 的进程应该显形了。

继续分析，这个动态库是怎么达到隐藏的目的呢？继续搜索，居然发现这个是个开源代码。看来人家本身不是病毒，只是一把刀，至于这把刀怎么用，那人家可不管。

实际上，很简单。这个动态库实现了一个 readdir 函数。由于启动进程时会预先加载这个库，因此当程序调用 readdir 时，实际上会先调用这里的 readdir 函数。只需要在这个函数里过滤掉病毒程序（.N5OYV5U）就好了。这样，当我们打开 top 的时候，top 程序会去 /proc 目录读取进程的 CPU 占用信息，但被过滤掉后就不会显示出来了。