Zabbix Server突然報“High swap space usage ( less than 50% free)”，簡單描述一下當前Zabbix Server環境，操作系統為CentOS 8，上面部署了MySQL與Zabbix-Server、PHP等組件。
[root@Zabbix ~]# more /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)
[root@Zabbix ~]# uname -m
x86_64
登錄Zabbix服務器檢查內存情況如下所示：
[root@Zabbix ~]# free -m
total used free shared buff/cache available
Mem: 7809 4911 153 71 2744 2529
Swap: 8099 4082 4017
[root@Zabbix ~]# cat /proc/zoneinfo |grep -E "Node|pages free|nr_inactive_anon|nr_inactive_file|min|low|high"|grep -v "high:"
Node 0, zone DMA
nr_inactive_anon 318071
nr_inactive_file 531494
pages free 3836
min 32
low 40
high 48
Node 0, zone DMA32
pages free 21648
min 6091
low 7613
high 9135
Node 0, zone Normal
pages free 14002
min 10771
low 13463
high 16155
Node 0, zone Movable
pages free 0
min 0
low 0
high 0
Node 0, zone Device
pages free 0
min 0
low 0
high 0
Linux服務器空閑的內存還有不少，但是使用了大量的Swap空間(使用接近一半的Swap分區）。使用vmstat觀察（si/so指標）也能看到有較頻繁的內存頁面置換到Swap分區或從Swap分區寫入到內存）
si：每秒從交換區寫到內存的大小；
so：每秒寫入交換區的內存大小；
[root@Zabbix ~]vmstat -an 1
我一度懷疑是服務器沒有禁用NUMA，導致MySQL耗用了大量的交換分區空間，因為MySQL的一個Bug#, 會導致MySQL在x86系統下存在嚴重的 “swap insanity” 問題，簡單來說，你把主機大部分內存分配給InnoDB時，你會發現明明操作系統還有很多內存，但是卻有很多內存被交換到了SWAP分區。網上也有大量這樣的案例，但是，分析過程中，我分析、統計哪些進程占用了swap 大小時，驚奇的發現php-fpm進程耗用大量的swap空間。如下所示
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r | less
重啟php-fpm服務，發現系統swap分區使用率急劇下降，看來確實是php-fpm的進程耗用了大量的swap空間
#systemctl restart php-fpm
在/etc/php-fpm.d/www.conf配置文件中，找到php的錯誤日志文件：php_admin_value[error_log] = /var/log/php-fpm/www-error.log， 但是在錯誤日志中僅僅看到“error log file re-opened”，自己對PHP不太熟悉，沒有繼續深入探究。
[root@Zabbix ~]# cd /var/log/php-fpm
[root@Zabbix php-fpm]# ls
error.log error.log-20201025 error.log-20201101 error.log-20201108 error.log-20201115
[root@Zabbix php-fpm]#more error.log
[15-Nov-2020 03:28:01] NOTICE: error log file re-opened
[18-Nov-2020 17:06:21] NOTICE: Terminating ...
[18-Nov-2020 17:06:21] NOTICE: exiting, bye-bye!
[18-Nov-2020 17:06:22] NOTICE: fpm is running, pid 205515
[18-Nov-2020 17:06:22] NOTICE: ready to handle connections
[18-Nov-2020 17:06:22] NOTICE: systemd monitor interval set to 10000ms
結論：
在診斷問題過程，我一度被“MySQL在x86系統下存在嚴重的 “swap insanity” 問題”這個先入為主的觀念給固定思維模式了，分析一直偏離了正確方向，直到我統計、查看哪些進程消耗了Swap空間時，才恍然大悟，然來是php-fpm進程異常了，然后又着急驗證猜想，重啟了php-fpm服務，導致一些問題沒法驗證，例如php-fmp的進程數量等等。另外，對於php不熟悉，不能進一步深入分析。不過倒是可以給一個簡單結論是:php-fpm異常了，導致其消耗了大量Swap空間，至於是內存泄露還是其它原因已經無法探究了！