☰

CPU 限制和 kswapd0 建议

tag-icon • tag-icon cpu-usage swap
CPU 限制和 kswapd0 建议

经过几个小时的测试，我发现适用于 ubuntu 20.04 的 nextcloud 桌面同步客户端（appimage 或 ppa）似乎都有一个错误，如果发生常见的 nextcloud 文件同步错误，kswapd0 会飙升至 100% 的 CPU，并且 Debian 10.5 服务器上的交换文件会完全填满。（在 kswapd0 攀升至 100% 的 CPU 期间，clamscan 也会飙升 45% 到 100%）。我的其他同步客户端不会导致此问题（移动、ubuntu 原生“在线帐户”）。

top 命令输出

top - 16:08:59 up 22 min,  2 users,  load average: 89.42, 84.04, 55.66
Tasks: 378 total,  12 running, 359 sleeping,   0 stopped,   7 zombie
%Cpu(s):  3.4 us, 57.0 sy,  0.0 ni,  0.1 id, 39.5 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3946.8 total,     90.2 free,   3766.4 used,     90.1 buff/cache
MiB Swap:   6144.0 total,      0.0 free,   6144.0 used.      4.9 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND           
   36 root      30  10       0      0      0 R  98.3   0.0  12:43.68 kswapd0           
 1691 mysql     20   0 1739540   2376      0 S   3.9   0.1   0:34.59 mysqld            
 1300 root      10 -10  116752   3400      0 D   3.3   0.1   0:41.96 AliYunDun         
 1544 root      20   0  806108    640      0 D   2.4   0.0   0:09.45 aliyun-service    
  161 root      20   0    4556   1904   1844 S   0.9   0.0   0:10.60 plymouthd         
 2746 git       20   0 1374728   6020      0 S   0.7   0.1   0:07.23 gitea             
 1114 root      20   0   24312    284      0 S   0.5   0.0   0:03.74 AliYunDunUpdate   
 5805 web2      20   0  292472 215456    920 D   0.4   5.3   0:05.43 clamscan          
  155 root       0 -20       0      0      0 I   0.3   0.0   0:07.11 kworker/0:1H-kbl+ 
  232 root      20   0   70888    284     88 D   0.3   0.0   0:03.74 systemd-journal   
  936 memcache  20   0  408168      0      0 S   0.3   0.0   0:02.19 memcached         
 3492 root      20   0   11380    756    556 R   0.3   0.0   0:03.28 top               
    1 root      20   0  170192   2972      0 D   0.3   0.1   0:11.03 systemd           
 1041 redis     20   0   54244    428      0 D   0.3   0.0   0:03.28 redis-server      
 4029 www-data  20   0  339376   2436     16 D   0.3   0.1   0:00.85 /usr/sbin/apach

我曾尝试使用 nice 和 cpulimit 来防止 kswapd0 达到 100% 并完全消耗交换内存。但 kswapd0 似乎只是通过两个命令（无论是单独运行还是同时运行）来供电，并且消耗 100% 的 CPU 和交换，让我别无选择，只能重新启动服务器以清除交换缓存。

我已经将 swapiness 降低到零。并且我尝试过：

To free pagecache:
    echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
    echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
    echo 3 > /proc/sys/vm/drop_caches

我认为 nextcloud 文件同步错误在未来会变得很常见，有人能建议我如何缓解/防止简单的文件同步错误导致整个服务器崩溃吗？

更新

经过一些额外的测试和阅读后，似乎 ClamAV 在每个上传和电子邮件上都运行 clamscan，这导致 CPU 使用率飙升至 100%。与 nextcloud 的关系是，我已激活文件防病毒程序。因此，我的文件同步上传也会启动 clamscan，然后导致服务器过载。

解决方案似乎是停止使用 clamscan，而是实施 clamav-daemon。我现在正在研究这个问题，但如果有人能告诉我如何从 clamscan 切换到 clamav-daemon。我将不胜感激。

答案1

上述问题本质上是 clamscan 造成的“错觉”。下面是我解决它的方法：

上述问题有两个方面，一是 amavis 运行的是 clamscan 而不是 clamd（几个月来一直没有出现任何问题，我想更新改变了一些东西），二是 nextcloud 防病毒软件默认使用 clamscan 而不是 clamd。因此，每当我连接 Nextcloud 客户端并看到“同步错误”时，它都隐藏了 clamscan 使服务器过载的事实，因为 nextcloud 用户的 clamscan 占用了大约 29% 的 CPU/文件同步。

通过完全禁用 nextcloud 同步并仅观察​​ top 命令，我发现了 amavis/clamscan 问题。

解决方案：

1.) #dpkg-reconfigure clamav-daemon #change amavis to run clamd (参见文档) <- 无论出于什么原因，此配置都不是永久的，系统在重启后会恢复。要永久限制 Debian/Ubuntu 机器上的 clamscan 的 CPU，请将以下内容添加
CPUAccounting=true CPUQuota=X%到：
#nano /etc/systemd/system/clamav-daemon.service.d/extend.conf
2.) 更改 nextcloud 的防病毒默认值从clamscan到clamav 守护进程（套接字）

这将解决你的问题。

有用的东西，但这里是可选的。对于那些使用默认安装了 systemd/cgroups 的 debian/ubuntu 操作共享托管环境的人来说。我找到了一个关于如何限制用户 CPU 使用率的优秀教程：

https://www.webhostingtalk.com/showthread.php?t=1832382

通过此功能，您可以限制用户的整体 CPU 使用率，以避免客户端因应用程序设置不当而导致服务器崩溃。

这个问题花了我4天时间..希望答案能对别人有帮助。

相关内容