精品軟體與實用教程
維運在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。
重新啟動後，速度是不是變快了！
