16人参与 • 2025-05-30 • https
ulimit -n 65535 # 设置当前会话的打开文件数限制
编辑 /etc/security/limits.conf
,末尾添加:
* soft nofile 65535 * hard nofile 65535 nginx soft nofile 65535 # 如果nginx以nginx用户运行 nginx hard nofile 65535
保存后退出,重启系统或重新登录会话生效。
编辑nginx主配置文件(通常为/etc/nginx/nginx.conf
):
# 在全局块添加 worker_rlimit_nofile 65535; # 设置每个worker进程最大可打开文件数 events { worker_connections 4096; # 每个worker允许的并发连接数 multi_accept on; # 允许一次性接受多个连接 } http { ... }
worker_rlimit_nofile ≥ worker_connections × worker_processes
worker_processes
默认为cpu核心数,可通过 auto
自动设置。cat /proc/sys/fs/file-max # 查看系统全局限制 # 若需临时修改: sysctl -w fs.file-max=200000 # 永久生效: echo "fs.file-max=200000" >> /etc/sysctl.conf sysctl -p
# 获取nginx主进程pid ps -ef | grep nginx | grep master # 查看该进程打开的文件数 lsof -p <pid> | wc -l
若接近限制,需进一步优化或排查泄漏。
检查后端应用:确认是否存在未关闭的数据库连接、文件句柄或http连接。
启用nginx长连接(减少频繁开闭):
http { keepalive_timeout 60; keepalive_requests 100; }
日志分析:检查是否有异常请求导致资源未释放,如频繁访问50x.html
可能需优化错误处理。
nginx -t # 验证配置语法 systemctl restart nginx # 根据系统选择重启命令
实时监控文件描述符:
watch -n 1 "ls /proc/$(pgrep nginx)/fd | wc -l"
日志跟踪:观察错误是否减少或消失。
通过上述步骤,可有效解决因文件描述符不足导致的nginx报错问题。
到此这篇关于nginx报错“too many open files”的问题解决的文章就介绍到这了,更多相关nginx too many open files内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论