記錄並分享一下最近工作中遇到的 Too many open files 異常的解決過程。 問題背景 產品有個上傳壓縮包並導入配置信息到資料庫中的功能，主要流程如下： 用戶上傳壓縮包； 後端解壓存放在臨時目錄，並返回列表給用戶； 用戶選擇需要導入哪些信息； 後端按需插入資料庫中，完成後刪除臨時目錄。 ...
記錄並分享一下最近工作中遇到的 Too many open files 異常的解決過程。
問題背景
產品有個上傳壓縮包並導入配置信息到資料庫中的功能，主要流程如下：
- 用戶上傳壓縮包；
- 後端解壓存放在臨時目錄，並返回列表給用戶；
- 用戶選擇需要導入哪些信息；
- 後端按需插入資料庫中，完成後刪除臨時目錄。
這個功能上線兩三年了，一直沒出現問題，最近測試在功能回歸時，導入的時候出現Too many open files異常。
但是通過lsof -p pid | wc -l查看當前進程打開的句柄數時，又是正常的。
Too many open files是Linux系統中常見的錯誤，字面意思就是說打開了太多的文件，超過了系統的限制。
這裡的文件（file）更準確的意思是文件句柄，或者是文件描述符。可以說，Linux系統里的一切都是文件，包括網路連接、埠等等。
lsof -p pid命令可以查看指定進程當前打開的文件信息。wc -l命令指按行統計。
問題分析
當時的第一反應是該系統的文件句柄數配置的太低了，因為在其他環境都是正常的。
通過ulimit -a命令，可以查看當前系統對各種資源的限制。
[uyong@linuxtest ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31767
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31767
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
open files 那行就是表示打開的文件數限制，即一個進程最多可以同時打開的文件數。
也可以通過
ulimit -n直接查看最大打開文件數量。
當時查出來的配置是4096，查看其他沒問題的環境上的配置，數量都是遠遠大於這個數。而且系統重新啟動後，沒做任何操作時，通過lsof -p pid | wc -l查看文件占用，只有100多個。在好的環境上執行導入成功後，再次查看，文件占用數不變。在有問題的環境上導入失敗後，查看文件占用數也是不變。
雖然當時的壓縮包文件很大，但4096按說也夠的。有點奇怪，為了不影響測試進度，只能先臨時修改系統配置，增大文件數限制，ulimit -n 65535命令執行後，再次導入沒問題了。
命令
ulimit -n 65536只能臨時臨時調整文件數量，系統重啟後配置就會失效。如果要永久生效，需要在配置文件
/etc/security/limits.conf里增加如下兩行：* soft nofile 65536 * hard nofile 65535
問題到此就結束了嗎，NO
