怎么排查文件句柄消耗過多？這篇文章運用了實例代碼展示，代碼非常詳細(xì)，可供感興趣的小伙伴們參考借鑒，希望對大家有所幫助。
背景：
隨著業(yè)務(wù)迭代，部分項目用nodejs重構(gòu)后，部署到k8s環(huán)境下運行。為了便于分析，上了一版代碼，增加輸出日志的功能。
現(xiàn)象：
上線半天后，發(fā)現(xiàn)研發(fā)反饋有收到報錯提示 too many open files 這種 打開文件過多的告警， 部分pod crash掉了，影響到用戶體驗。
同時，運維查看監(jiān)控，可以看到文件句柄使用量在短時間內(nèi)劇增，如下圖：
運維查看問題k8s節(jié)點的文件句柄使用情況
ulimit -n # 查看當(dāng)前用戶可用大句柄 sysctl -a | grep fs.file-max # 查看內(nèi)核級的文件句柄大限制值 cat /proc/sys/fs/file-nr # 查看當(dāng)前已用的文件句柄數(shù)量 和 內(nèi)核級的文件句柄限制的大值 可以看到的是問題k8s節(jié)點的 cat /proc/sys/fs/file-nr 的已用文件句柄數(shù)量基本用滿了。
運維側(cè)的快速解決方法：
vim /etc/sysctl.conf 增加一行配置 fs.file-max = 13129438 # 調(diào)大這個值（這個值如果不人工指定的話，linux是會根據(jù)每臺服務(wù)器的硬件配置自動設(shè)置的，可以看到64G和128G內(nèi)存的主機，這個值是不同的） sysctl -p 使上面調(diào)整文件句柄的操作立即生效 然后，將這個節(jié)點從k8s集群摘除掉（并將pod趕到其它正常節(jié)點上）。無法釋放的文件句柄，我們只能通過重啟服務(wù)器來釋放出來。 并猜測可能是最近新上的nodejs項目打日志的姿勢不對造成的。
下面是在 k8s worker-node13 節(jié)點抓取的lsof信息（只要跑有這個異常的pod的k8s-worker-node的就可以去執(zhí)行下lsof看下，畢竟如果有句柄未關(guān)閉，肯定這個系列的全部pod都有問題）：
lsof > /tmp/lsof # 得出的文件差不多2GB大小 (這個過程比較漫長，可能需要5-10分鐘）
[root@k8s-worker-node-13 ~]# cat /tmp/lsof | grep -c java
3422
[root@k8s-worker-node-13 ~]#cat /tmp/lsof | egrep -c '\bnode\b'
14621626
[root@k8s-worker-node-13 ~]# cat /tmp/lsof | egrep '\bnode\b' | less 查看過濾出來的日志文件
TID列為空 COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME node 16966 root 458w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 459w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 460w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 461w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 462w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 463w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 464w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 465w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 466w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 467w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 468w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 469w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 470w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 471w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 472w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json node 16966 root 473w REG 253,1 671641730 1572898 /usr/src/app/log/test-app/test-app-2020-03-11.json 。。。。。 省略部分內(nèi)容 。。。。。 node 20927 20955 root mem REG 253,16 6823953 /usr/lib/libgcc_s.so.1 (stat: No such file or directory) node 20927 20955 root mem REG 253,16 6823955 /usr/lib/libstdc++.so.6.0.22 (stat: No such file or directory) node 20927 20955 root mem REG 253,16 6030733 /lib/ld-musl-x86_64.so.1 (stat: No such file or directory) node 20927 20955 root mem REG 253,16 6030679 /etc/localtime (path dev=253,1, inode=788097) node 20927 20955 root 23w REG 0,460 717345 9178728 /tmp/access-20200311.log node 20927 20955 root 27w REG 0,460 209117 9178762 /tmp/tracing-20200311.log node 20927 20955 root 29w REG 0,460 209117 9178762 /tmp/tracing-20200311.log node 20927 20956 root txt REG 0,460 40885256 7079234 /usr/local/bin/node node 20927 20956 root mem REG 253,16 7079234 /usr/local/bin/node (stat: No such file or directory) node 20927 20956 root mem REG 253,16 6823953 /usr/lib/libgcc_s.so.1 (stat: No such file or directory) node 20927 20956 root mem REG 253,16 6823955 /usr/lib/libstdc++.so.6.0.22 (stat: No such file or directory) node 20927 20956 root mem REG 253,16 6030733 /lib/ld-musl-x86_64.so.1 (stat: No such file or directory) node 20927 20956 root mem REG 253,16 6030679 /etc/localtime (path dev=253,1, inode=788097) node 20927 20957 root txt REG 0,460 40885256 7079234 /usr/local/bin/node node 20927 20957 root mem REG 253,16 7079234 /usr/local/bin/node (stat: No such file or directory) node 20927 20957 root mem REG 253,16 6823953 /usr/lib/libgcc_s.so.1 (stat: No such file or directory) node 20927 20957 root mem REG 253,16 6823955 /usr/lib/libstdc++.so.6.0.22 (stat: No such file or directory) node 20927 20957 root mem REG 253,16 6030733 /lib/ld-musl-x86_64.so.1 (stat: No such file or directory) node 20927 20957 root mem REG 253,16 6030679 /etc/localtime (path dev=253,1, inode=788097) node 20927 20957 root 23w REG 0,460 717345 9178728 /tmp/access-20200311.log node 20927 20957 root 27w REG 0,460 209117 9178762 /tmp/tracing-20200311.log node 20927 20957 root 29w REG 0,460 209117 9178762 /tmp/tracing-20200311.log node:Log 20927 21094 root txt REG 0,460 40885256 7079234 /usr/local/bin/node node:Log 20927 21094 root mem REG 253,16 7079234 /usr/local/bin/node (stat: No such file or directory) node:Log 20927 21094 root mem REG 253,16 6823953 /usr/lib/libgcc_s.so.1 (stat: No such file or directory) node:Log 20927 21094 root mem REG 253,16 6823955 /usr/lib/libstdc++.so.6.0.22 (stat: No such file or directory) node:Log 20927 21094 root mem REG 253,16 6030733 /lib/ld-musl-x86_64.so.1 (stat: No such file or directory)
開發(fā)側(cè)的解決方法：
回退服務(wù)，并排查代碼里面打日志的地方是否有問題。 后續(xù)，第二天后，開發(fā)反饋，他們之前的打日志寫的有問題，都是持續(xù)打開文件，沒有做close關(guān)閉動作，導(dǎo)致文件句柄不釋放。
運維側(cè)的優(yōu)化方案：
1、增加相關(guān)的監(jiān)控（node_exporter即可） 監(jiān)控表達(dá)式： node_filefd_allocated/ node_filefd_maximum * 100 > 70 就觸發(fā)告警，提示文件句柄占用超過70%，需要運維介入查看分析 2、對docker image里面的內(nèi)核參數(shù)做限制（還沒測試這招是否有效，待實戰(zhàn)驗證） 理由：docker鏡像里面也是個精簡版的linux，我們發(fā)現(xiàn)生產(chǎn)環(huán)境的image里它的默認(rèn)的fs.file-max 和 ulimt -n設(shè)置的非常大，我們可以考慮將ulimit -n 調(diào)低到 65535 ， 將 fs.file-max 調(diào)低到 655350。 這樣即便這個pod出問題后，只能影響到它自己，而不會連累到宿主機的上運行的其他pod。
看完上述內(nèi)容，你們對排查文件句柄消耗過多的方法大概了解了嗎？如果想了解更多相關(guān)文章內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)網(wǎng)站制作公司行業(yè)資訊頻道，感謝各位的閱讀！
重慶分公司
重慶分公司
