kswapd0 占用了我 99.9% 的 CPU，正如 top 显示的那样，今天玩游戏时出现问题，第一次在 6 分钟后消失，现在已经持续了大约 20 分钟。这是如何修复的，是什么原因造成的？
Zzz*_*... 83
进程 kswapd0 是管理虚拟内存的进程。您的机器的 HDD/SSD 上应该有 RAM、SWAP 和 EXT4。ext4 是存储所有东西的地方，它的访问速度总是比 RAM 慢。RAM就像是程序快速访问信息的中途运行空间。大多数计算机至少有 4GB 的 RAM，这在正常情况下已经足够了。但是，在玩游戏时，您可能会耗尽 RAM 空间，而这正是 SWAP 的用武之地。
SWAP 是位于 HDD/SSD 上 EXT4 旁边的假 RAM。访问速度比 EXT4 快，但比实际 RAM 慢得多。当您的内存不足时，kswapd0 会将您不使用/不使用与其他程序一样多的程序移动到 SWAP，这会导致这些进程极度滞后。如果您的游戏需要 5GB RAM，则至少 1GB 将处于 SWAP 中。这意味着当它试图访问该信息时，它必须等待更长时间才能获得它。
这整个过程会导致 CPU 使用率极高，将信息从 SWAP 和 RAM 移出和移到 SWAP 和 RAM，并同时处理所有信息请求。如何解决这个问题？
告诉 kswapd0 仅在您完全没有 RAM 时才将内容移至 SWAP。这是解决 SWAP 问题的最有效的方法。跑
echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf
哪里0是100应该使用 SWAP的百分比（当您有 0% 的 RAM 时，SWAP 将开始接收数据）。您也可以根据自己的喜好编辑 /etc/sysctl.conf，而不是每次使用 gedit 或 nano 或其他任何方式将此命令添加到它的末尾，但请务必使用 sudo，该文件是 root 拥有的。重新启动，你的设置！
这是你能做的最好的事情。其他人可能会说完全禁用交换，但这很危险，我不建议这样做。如果存在内存泄漏或运行的应用程序过多，这可能会导致整个系统冻结。只要意识到 SWAP 是 RAM 的故障保护。它绝对不如 RAM 快或高效，但它比 Window 的 Pagefile 好！（实现相同的目的）
编辑：如果您有兴趣了解有关 SWAP 的更多信息，请参阅此处。
Mar*_*egg 41
对我来说，它有时会在 Ubuntu 14.04 上发生，内核 3.19.0-50-generic（及更早版本）在 VMware 虚拟机中运行。我不知道是什么让它出现的，但它是在空闲时间出现的。
top 显示：
# top
top - 09:49:35 up 5 days, 18:35, 1 user, load average: 1.00, 1.00, 0.99
Tasks: 219 total, 2 running, 217 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 25.0 sy, 0.0 ni, 74.7 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 3028784 total, 1874468 used, 1154316 free, 1010276 buffers
KiB Swap: 15624188 total, 3032 used, 15621156 free. 234928 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
52 root 20 0 0 0 0 R 99.7 0.0 122:15.21 kswapd0
3 root 20 0 0 0 0 S 0.3 0.0 0:29.86 ksoftirqd/0
7 root 20 0 0 0 0 S 0.3 0.0 9:49.47 rcu_sched
重新启动解决了问题 - 暂时。
按照serverfault上的答案（当使用交换时，kswapd 通常使用 100% CPU），那里在我的系统上有相同的设置：
# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
该解决方案实际上echo 1 > /proc/sys/vm/drop_caches是以 root 用户身份运行的：
# cat /proc/sys/vm/drop_caches
0
# echo 1 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
1
或者，正如theTuxRacer所指出的（谢谢！），如果您没有以 root 身份登录，请使用以下命令：
echo 1 | sudo tee /proc/sys/vm/drop_caches
现在好了：
# top
top - 10:08:58 up 5 days, 18:55, 1 user, load average: 0.72, 0.95, 0.98
Tasks: 220 total, 1 running, 219 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.2 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3028784 total, 681704 used, 2347080 free, 2916 buffers
KiB Swap: 15624188 total, 3032 used, 15621156 free. 81924 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9 root 20 0 0 0 0 S 0.3 0.0 14:10.40 rcuos/0
1 root 20 0 45652 8124 2888 S 0.0 0.3 1:54.98 init
但由于实际原因尚不清楚，我也没有在网上找到任何合适的解释，所以这不是一个永久的解决方案。实际上，选定的答案可能是永久解决方案。我只是想添加这个以供将来参考，因为重启（使 sysctl 生效）并不总是可行的。
另一种解决方案可能是将 THP 设置为madvice或never（参见poige对他的回答的评论，如何修改“/sys/kernel/mm/transparent_hugepage/enabled”和参考的禁用透明大页面（THP）的MongoDB 手册）
我已将以下批次设置为 cron 作业作为“永久”解决方案：
#!/bin/bash
# Rev 2: Use ps instead of top
## run as cron, thus no $PATH, thus need to define all absolute paths
cpu=$(/usr/bin/printf %.0f $(/bin/ps -o pcpu= -C kswapd0))
[[ -n $cpu ]] \
&& (( $cpu >= 90 )) \
&& echo 1 > /proc/sys/vm/drop_caches \
&& echo "$$ $0: cache dropped (kswapd0 %CPU=$cpu)" >&2 \
&& exit 1
exit 0
从root@localhost:~# crontab -ewith调用
# m h dom mon dow command
* * * * * /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1
注意：上面的 cron 作业脚本已经修改为包含Fredrik Erlandsson的建议：一种更简单、更有效的方法来确定 kswapd0 的 CPU 使用率。谢谢！
mch*_*hid 13
更持久的解决方案是增加交换文件的大小。
当搜索不存在的交换空间时（如果你的交换分区已满），kswapd 将占用 100% 的 CPU。htop将在屏幕顶部显示您的交换空间是否已满，或者您可以使用该free -h命令检查已使用的交换空间。
使用以下命令将交换文件的大小从 4GB 增加到 8GB 后，kswapd 现在以 0% CPU 运行，swappiness 设置为 60 *。
sudo swapoff /swapfile
sudo rm /swapfile
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
这假设您已经在使用交换文件（默认 Ubuntu 设置）并且/swapfile在/etc/fstab. 此外，您的交换文件可能会更大或更小，具体取决于您有多少 RAM，因此请进行相应调整。
* 需要注意的是，我使用的是 SSD，因此磁盘性能不是问题。然而，如果内存不足，交换几乎总是一件好事。
如果您在系统运行一天或更长时间而没有重新启动时遇到交换分页过多和系统冻结等问题，请参阅此相关答案。此问题具有非常相似的症状，但原因不同。因此，如果问题再次出现，您可能需要尝试此替代解决方案。
| 归档时间： |
|
| 查看次数： |
182076 次 |
| 最近记录： |