CPU 限制和 kswapd0 建議

CPU 限制和 kswapd0 建議

經過幾個小時的測試,我發現 ubuntu 20.04 的 nextcloud 桌面同步客戶端(appimage 或 ppa)似乎都有一個錯誤...如果發生常見的 nextcloud 文件同步錯誤,kswapd0 會飆升至 100% CPU 並且Debian 10.5 伺服器上的交換文件已完全填滿。 (在 kswapd0 爬升至 100% 的 CPU 期間,clamscan 的峰值也達到 45% 至 100%)。我的其他同步用戶端不會導致此問題(行動、ubuntu 原生「線上帳戶」)。

頂部命令輸出

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和交換,讓我別無選擇,但重新啟動伺服器以清除交換快取。

我已經將交換性降到零。我已經嘗試過:

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。我會很感激。

到目前為止我已經嘗試過:

service clamd start
Failed to start clamd.service: Unit clamd.service not found.

# freshclam -d
ERROR: /var/log/clamav/freshclam.log is locked by another process
ERROR: Problem with internal logger (UpdateLogFile = /var/log/clamav/freshclam.log).
ERROR: initialize: libfreshclam init failed.
ERROR: Initialization error!

答案1

好的...我破解了...上面的問題是雙重的,這意味著 amavis 正在運行 clamscan 而不是 clamd,同時 nextcloud 防毒軟體預設使用 clamscan 而不是 clamd。

解決方案:

1.) #dpkg-reconfigure clamav-daemon <- 無論出於何種原因,此配置都不是永久性的,系統在重新啟動後會恢復。若要在 Debian/Ubuntu 機器上對 clamscan 設定 CPU 限制的永久方法,請將:新增
CPUAccounting=true CPUQuota=X%至:
#nano /etc/systemd/system/clamav-daemon.service.d/extend.conf
2.) 變更 nextcloud 的防毒預設值蛤掃描clamav 守護程式(套接字)

這將解決您的問題。現在,nextcloud 可以有任意數量的 snyc 錯誤,而無需關閉整個伺服器。

一些有用的東西,但這裡是可選的。對於使用 debian/ubuntu 操作共享託管環境的人來說,預設安裝了 systemd/cgroups。我發現了一個關於如何限制使用者 CPU 使用率的優秀教學:

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

透過此功能,您可以限制使用者的整體 CPU 使用率,以避免客戶端因應用程式設定不當而導致伺服器崩潰。

相關內容