某台小鸡上面跑的 Seafile 的 ElasticSearch 太吃文件句柄数了(因为是 Java 开发的） ，也可能是我设置不当，导致 Seafile 运行几个小时就报 Too many open files。

网上搜索的资料都很不负责任，这里推荐下面引用的大佬的微信公众号【开发内功修炼】，详细说明了原因和修改办法，并且深度扒了内核源码和详细分析，还给了漫画图解，非常深刻！看完之后简直是醍醐灌顶。

刨根问底儿，看我如何处理 Too many open files 错误！https://mp.weixin.qq.com/s/GBn94vdL4xUL80WYrGdUWQ
漫画 | 一台Linux服务器最多能支撑多少个TCP连接？ https://mp.weixin.qq.com/s/Lkyj42NtvqEj63DoCY5btQ
漫画 | 理解了TCP连接的实现以后，客户端的并发也爆发了！ https://mp.weixin.qq.com/s/ta6upubg0o1w03YGUo8Trg

本文在以上内容增加了一点变化，增加了 root hard nofile 相关的配置，因为测试时发现，对于 root 用户，必须要特别指定用户名，才能生效，不想细看的话，就这么操作，永久性修改：

vim /etc/sysctl.conf

修改或增加如下内容：

fs.nr_open=11000000  
fs.file-max=11000000 

然后 sysctl -p ，使其立刻生效。

vim /etc/security/limits.conf，在文件末尾追加如下四行：

*  soft  nofile  10000000
*  hard  nofile  10000000
root  hard    nofile   10000000
root  soft    nofile   10000000

注意，最后两行是我实践发现的，我用的是 root 用户，修改完之后重启系统也没生效，查询谷歌之后，发现部分系统，还需要特别指定 root 用户名。

修改完之后重启系统，以上这套方案可以支撑同时打开 一千万个文件描述符，远远大于默认 1024 的限制。

然后执行 ulimit -a 查看限制。

测试环境：Ubuntu 20.04.3 LTS，内核：Linux 5.15.8-rt23-xanmod（这是一个第三方内核，见 https://www.xanmod.org/），用户权限：root

也在 CentOS 7.9 / CentOS 8.2 测试通过。

输出如下：

root@ubuntu:~# 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) 31571
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 10000000
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) 31571
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited