我看到 kswapd 使用了 100% 的 CPU...我怎样才能知道哪个进程的 kswapd 使用得这么多？
答案1
kswapd 正在管理交换空间以应对超出物理可用内存需求的情况全部流程。
它与过程无关，它仅对访问哪些页面以及何时访问感兴趣（当然，它比这更复杂，但为了简单起见，我们也可以这样看待它）。
所以真实的问题是“哪些进程的内存负担最大，导致 kswapd 需要一直进行分页”。
最容易回答这个问题的方法是使用“top”并切换到内存使用排序模式。
答案2
您可以编写脚本，但您也可以通过 top 来完成
运行 top 然后按哦其次是页然后进入
现在所有进程都按交换使用情况排序，你可以看到哪些进程正在使用它
答案3
答案4
某个地方似乎还存在一个错误kswapd，希望只出现在较旧的内核上。
现在，几乎每天，kswapd 都会在大型集群中的某些机器上随机失控（尽管使用的是非当前内核）。两个 kswapd 进程的 CPU 都达到 100%。没有其他正在运行的进程（ssh shell 除外），有大量可用 RAM（超过 700 MB），并且根本没有使用 SWAP。没有 swapin，也没有 swapout。
目前还没有解释为什么某台机器会受到影响而另一台不会。这似乎不是完全随机的，因为它通常会在短时间内影响多台机器。看起来空闲的机器以及处于高压下的机器不太可能受到这种影响。因此，它必须与工作负载有关，并且只有当机器既不空闲也不太繁忙时才会受到影响。
如果问题再次出现，那么什么方法都无济于事。终止所有进程（不是不可终止的进程），卸载所有文件系统，都无济于事。CPUkswapd仍然保持在 100%。我怀疑 SMP 内核中存在一些自旋锁竞争，但我也可能错了。
也许看到我的回答serverfault.com/questions/316995/#493257
笔记：
- 重新启动受影响的机器通常会失败，因为关机过程开始在某处挂起。
- 没有直接连接到互联网。外部原因的可能性不大。
- 从负载的角度来看，这似乎取决于机器处理的工作负载类型，因为我们的机器从未受到影响（迄今为止）。
- 抱歉，我无法具体说明我们做什么以及为什么这样做。
- 是的，我在猜测。因为今天这是一个极其令人费解的效应。