우수한 소프트웨어와 실용적인 튜토리얼
运维在Ubuntu中常遇到的大坑，“Too many open files in system!”
服务器运行缓慢，经常报错520或521错误，然后CPU和内存使用都不高，硬盘也没有跑满，遇到这样的问题很多人以为问题出在PHP上，其实除了PHP性能之外，还有一个重要的因素，那就是文件系统资源耗尽，听着挺不可思议的，没错，就是在Ubuntu中可以打开的文件数超限了！
在网络上搜索了一下，遇到这类问题的还挺多的！下面就教大家如何快速解决这个问题！
“Too many open files in system!” 这个错误是 Linux/Ubuntu 系统常见的资源限制问题，表示服务器的文件描述符（file descriptors）已耗尽，无法打开新连接。 在 CyberPanel 或 LiteSpeed 环境中（如 HttpListener 用于 Web 服务器），高流量时 Nginx/Apache/MySQL 等进程打开过多 socket/file，导致 "Too many open files" 崩溃。您的 CPU/内存/硬盘正常，确认是描述符瓶颈（默认用户限 1024，全局 65536）。这会中断新请求，放大 520/504 错误率 50%+。 幸运的是，修复只需调整 ulimit 和 sysctl，5-10 分钟生效。
"Too Many Open Files" 错误排查与解决：Ubuntu 服务器高打开文件数分析
在 Ubuntu/Linux 服务器管理中，"Too many open files in system!" 错误是典型的资源耗尽信号，表示系统文件描述符（file descriptors）上限被触顶，无法打开新文件或 socket 连接。 您的日志显示 ulimit -n = 65535（用户/进程限制）和 /proc/sys/fs/file-max = 65535（全局系统限制），但 lsof | wc -l = 2211319（当前打开文件数），远超上限。这不是硬件问题（CPU/内存/硬盘正常），而是文件句柄泄漏或高并发应用（如 Web 服务器、数据库）未及时关闭连接导致的积累。根据 Server Fault 和 Ask Ubuntu 社区经验，90% 案例源于 Nginx/Apache/MySQL 进程句柄未释放，在流量峰值时雪崩式爆发，引发 502/504 错误或服务崩溃。幸好，这可通过临时/永久限额提升和进程诊断快速修复。
排查打开文件：谁打开了什么？
用 lsof 工具（已安装）分类诊断，按进程/类型查看：
lsof | wc -l
按进程查看打开文件数（找出罪魁祸首）：
lsof | awk '{print $2}' | sort | uniq -c | sort -nr | head -10 # 列出前 10 高进程实时监控：watch -n 5 'lsof | wc -l' 每 5 秒刷新，观察增长。
系统默认的最大文件配额是65535 如果打开的文件大于65535之后，所有打开的文件需要进入列队等候，这时候访问操作都会变得缓慢。
解决方法：提升限额与根源修复
编辑/etc/security/limits.conf文件，增加配额
sudo vi /etc/security/limits.conf
拉到最下面，将65535全部改成4194304
然后编辑/etc/sysctl.conf文件
vi /etc/sysctl.conf
修改 fs.file-max 参数：
fs.file-max = 4194304
应用配置文件：
sudo sysctl -p
全部设置完毕后重启 sudo reboot。
重新启动后，速度是不是变快了！
