kswapd0正在占用大量CPU

顶部kswapd0正在占用我99.9％的CPU，这是今天出现的问题，游戏在6分钟后首次消失，现在已经运行了20分钟左右。这是如何修复的，是什么引起的？

进程kswapd0是管理虚拟内存的进程。您的计算机应在HDD / SSD上具有RAM，SWAP和EXT4。ext4是存储所有内容的地方，并且访问速度总是比RAM慢。RAM就像程序的中途运行空间一样，可以快速访问信息。大多数计算机至少有4GB的RAM，在正常情况下足够。但是，在玩游戏时，RAM空间不足，而这正是SWAP的用武之地。

SWAP是位于EXT4旁边的HDD / SSD上的伪造RAM。访问速度比EXT4快，但比实际RAM慢得多。当内存不足时，kswapd0会将未使用/未使用的程序移至SWAP，这会导致这些进程极度滞后。如果您的游戏需要5GB的RAM，则至少需要1GB的SWAP内存。这意味着，当它尝试访问该信息时，必须等待更长的时间才能获取它。

这整个过程导致CPU使用率过高，将信息往返于SWAP和RAM以及同时处理信息请求。如何解决这个问题？

1. 告诉kswapd0仅在完全用尽RAM时才将内容移动到SWAP。这是解决SWAP问题的最有效方法。跑

   echo vm.swappiness=0 | sudo tee -a /etc/sysctl.conf

   其中应使用SWAP的0剩余百分比是100多少（当剩余RAM为0％时，SWAP将开始接收数据）。您也可以根据自己的喜好编辑/etc/sysctl.conf，而不必每次使用gedit或nano或其他命令将此命令添加到命令末尾，但请务必确保sudo该文件是root拥有的。重新启动，您已设置好！

2. 减少其他进程占用的RAM或在运行高内存程序时关闭其他程序。这就是为什么大多数游戏会告诉您在玩游戏之前关闭所有其他窗口，或者安装过程也是如此。诸如文件同步服务之类的东西往往会占用大量内存。
3. 购买更多的RAM。安装RAM并不像听起来那样难。在小隔间（如果您在笔记本电脑上）上拧一两颗螺钉，然后单击一下即可。只要确定您购买的是正确的那种！
4. 与使用RAM一样，降低CPU的进程。这将帮助那些RAM到SWAP的突发更加平滑。

那是您所能做的最好的。其他人可能会说完全禁用掉交换功能，但这很危险，我不建议这样做。如果存在内存泄漏或正在运行的应用程序过多，则可能导致整个系统冻结。只需意识到SWAP对于RAM是故障安全的。它绝对不如RAM快或高效，但是它比Window的Pagefile更好！（实现相同的目的）

编辑：如果您有兴趣了解有关SWAP的更多信息，请参见此处。

kswapd0以一个CPU的99.9％运行，但实际上根本不交换

对我而言，它有时会在Ubuntu 14.04上运行，而内核3.19.0-50-generic（或更早版本）在VMware vm中运行。我不知道是什么使它出现的，但是它是在空闲时间出现的。

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：

# cat /proc/sys/vm/drop_caches
0
# echo 1 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
1

现在很好：

# 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”和参考的MongoDB 禁用透明大页面手册（THP））

计划工作

我将以下批处理作为cron作业设置为“永久”解决方案：

#!/bin/bash


## run as cron, thus no $PATH, thus need to define all absolute paths
top=/usr/bin/top
grep=/bin/grep


top=$($top -bn1 -o \%CPU -u0 | $grep -m2 -E "%CPU|kswapd0")

IFS='
'
set -f

i=0

for line in $top
do
        #echo $i $line

        if ! (( i++ ))
        then
                pos=${line%%%CPU*}
                pos=${#pos}
                #echo $pos
        else
                cpu=${line:(($pos-1)):3}
                cpu=${cpu// /}
                #echo $cpu
        fi

done

[[ -n $cpu ]] && \
(( $cpu >= 90 )) \
&& echo 1 > /proc/sys/vm/drop_caches \
&& echo "$$ $0: cache dropped (kswapd0 %CPU=$cpu)" >&2 \
&& exit 1

exit 0

用

# m h  dom mon dow   command
  * *  *   *   *     /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1

16.04 14.04 交换