发布于2026-07-07 阅读(0)
扫一扫,手机访问
说到那个经典的“too many open files”,银河麒麟V10上要处理起来,其实路子挺清晰的,总结下来就三种:用户级的永久配置、针对特定服务的systemd设置,还有进程级的在线调整。要我说啊,这事儿其实分三种路数,咱们一个一个来看。
先交代一下背景。在银河麒麟V10里跑高并发服务,比如nginx,最烦的就是突然蹦出个“too many open files”,或者线程数超额、堆栈溢出,直接进程就崩了。所以,把资源限制配好,是稳定运行的大前提。
这个方法最实在,也最安全,生产环境里用得最多。它会把限制写进系统全局配置里,对所有的普通用户,以及之后启动的shell子进程都生效。
操作步骤不复杂:
用sudo nano /etc/security/limits.conf 打开配置文件,在文件末尾加四行,但必须提醒的是,星号和数值之间必须有空格,要不然系统解析会失败,那就白忙活了。
∗ soft nofile 65536
∗ hard nofile 65536
∗ soft nproc 65536
∗ hard nproc 65536
保存退出后,最关键的一步:必须重新登录当前用户会话。旧终端窗口不会继承新限制的。验证也很简单,在终端里敲 ulimit -n 和 ulimit -u,如果都输出65536,那就说明配上了。
有时候,比如nginx或者redis,它们需要的内存、CPU配额和普通进程不一样。为了不让一个服务的配置影响到其他进程,就得用systemd服务级的限制。
这里有两种搞法:
临时设置(重启后失效):适合应急测试。执行 sudo systemctl set-property nginx.service MemoryLimit=1G,然后 sudo systemctl daemon-reload,最后 sudo systemctl restart nginx。
持久化配置(强烈推荐):正式用这个。执行 sudo systemctl edit nginx.service,在弹出的空白文件里输入:
[Service]
MemoryLimit=1G
CPUQuota=75%
保存后不需要reload,systemd会自动把配置合并进去。想知道配没配好?用 sudo systemctl show nginx.service | grep -E "MemoryLimit|CPUQuota" 瞧一眼就知道了。
有时候服务器正跑着,突然文件描述符占满了,又不能重启进程,这时候就需要用在线调整来救场。不过得注意,这个方法只能针对特定的PID,而且不能突破ulimit里“hard”那个硬上限。
步骤也简单:
第一步,找到目标进程的PID。比如找nginx主进程:ps -eo pid,comm | grep nginx | head -1。
第二步,检查它当前的限制情况:cat /proc/【PID】/limits | grep "Max open files"。
第三步,用root权限,向这个进程的limits文件写入新值:echo -n "65536" > /proc/【PID】/limits/nofile。
必须提醒的是,这个操作是不可逆的。如果写的值不是数字,或者超出了内核允许的范围,写入会失败,而且没有任何提示信息。如果写对了,那就是立刻生效,完全不用重启进程,这点倒是不错。
话说到这,其实三种方法各有各的适用场景。生产环境里,通常都是用户级永久配置打底,再给重要的服务单独设限,偶尔遇到突发情况就用在线调整来兜底。把这套组合拳玩熟了,碰上高并发场景心里就踏实多了。