Linux「Too many open files」錯誤徹底解決：ulimit、sysctl、limits.conf 三層調優實戰

當程式 (如 Java、Nginx、MySQL) 同時開啟大量檔案描述符超過系統預設上限 (通常 1024)，即會拋出「Too many open files」。本文從臨時調整、永久生效、核心參數、使用者層級限制四個層面，提供完整解決方案與驗證方法。

快速診斷

# 查看核心級最大檔案數
cat /proc/sys/fs/file-max
# 查看當前 Shell 進程軟限制
ulimit -n
# 查看特定進程已開啟檔案數
lsof -p  | wc -l

層級 1：臨時調整 (當前 Shell 及子進程)

ulimit -n 65535   # 立即生效，僅限當前 Shell 及其後啟動的進程

層級 2：使用者永久限制 (/etc/security/limits.conf)

編輯 /etc/security/limits.conf，新增：

* soft nofile 65535
* hard nofile 65535
root soft nofile 65535
root hard nofile 65535

• soft：使用者可自行調整的上限 (≤ hard)。
• hard：唯有 root 可提高的天花板。
• * 代表所有使用者；生效需重新登入或重啟。

同步檢查 /etc/pam.d/common-session (Debian/Ubuntu) 或 /etc/pam.d/login (CentOS/RHEL) 是否包含：

session required pam_limits.so

層級 3：核心參數永久生效 (/etc/sysctl.conf)

fs.file-max = 2097152
fs.nr_open = 2097152   # 核心 2.4+ 單進程上限

sysctl -p   # 立即套用

層級 4：Systemd 服務單元限制 (適用 systemd 管理的服務)

編輯服務單元 (如 /etc/systemd/system/nginx.service.d/limits.conf)：

[Service]
LimitNOFILE=65535
LimitNPROC=65535

systemctl daemon-reload
systemctl restart nginx

額外網絡核心優化 (高併發場景)

# /etc/sysctl.d/99-tcp-tuning.conf
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535

sysctl --system

驗證成果

# 以目標使用者身份開新 Shell
ulimit -n
# 應顯示 65535

# 啟動服務後檢查
lsof -p $(pgrep -f java) | wc -l
# 應能超過 4000 不報錯

常見坑點

• su/sudo 不繼承 limits：su - user 會重新讀取 limits.conf，但 sudo cmd 預設重置環境，需在 /etc/sudoers 加入 Defaults>user env_keep += "LIMITS" 或改用 systemd 管理。
• /etc/rc.local 已棄用：勿在其中放 ulimit，改用上述 systemd 或 limits.conf。
• 容器環境：Docker 預設 --ulimit nofile=1024:4096，需在 docker run 或 docker-compose.yml 額外指定。

依據環境依序套用上述層級，即可徹底根除「Too many open files」困擾。