線上兩臺 keepalived + lvs
機器,內存都被 slab
佔光了,觀察是 dentry
所佔用的,通過排查,是由於keepalived
的 misc
調用 bash
腳本引發的。即便不是 misc
調用, bash
本身的正常的調用也會引發 slab
內存持續升高(使用 while 命令進行測試)。可是測試環境不是這樣。bash
...略過許多排查步驟。
使用 strace
命令跟蹤腳本的調用,發現 B
腳本的系統調用特別多,並且此腳本的運行速度明顯慢於 A 腳本。 curl
這兩個腳本的區別在於一個檢測 http 服務,一個檢測 https 服務。那麼可能就是在 https 這裏出的問題。ide
什麼緣由呢?因而將 strace
的結果輸出到一個文件裏,在文件裏觀察發現最多的就是 access("/etc/pki/nssdb/.273583784_dOeSnotExist_.db", F_OK) = -1 ENOENT (No such file or directory)
。查看此目錄是由 nss 這個包產生的測試
[root@SZ-CORE-LVS-02 keepalived]# rpm -qf /etc/pki/nssdb/ nss-3.28.4-4.el6_9.x86_64
,而後搜索了 /etc/pki/nssdb/.273591295_dOeSnotExist_.db
這個錯誤,發現了下面的幾個連接,
原來這是 nss-softokn 的一個 bug, 有修改源碼的方式,可是那樣還得從新編譯,最簡單的方式就是
配置一個環境變量。export NSS_SDB_USE_CACHE=no
,一句話,立竿見影,slab 穩定了。世界安靜了。url
centOS6
當使用 curl
命令訪問 https
服務的時候就會產生這個狀況(由於nss-softokn
這個包的 bug ),調用頻繁就會使得 slab 內存持續明顯上升。code