记一次奇怪的文件句柄泄露问题，问题背景产品有个上传

记一次奇怪的文件句柄泄露问题，问题背景产品有个上传

记录并分享一下最近工作中遇到的 Too many open files 异常的解决过程。

问题背景

产品有个上传压缩包并导入配置信息到数据库中的功能，主要流程如下：

1. 用户上传压缩包；
2. 后端解压存放在临时目录，并返回列表给用户；
3. 用户选择需要导入哪些信息；
4. 后端按需插入数据库中，完成后删除临时目录。

这个功能上线两三年了，一直没出现问题，最近测试在功能回归时，导入的时候出现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