说到经典的“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" 查看一下就清楚了。
在线调整正在运行进程的nofile限制
有时候服务器正跑着，突然文件描述符占满，又不能重启进程，这时候就需要用在线调整来救急。不过要注意，这个方法只能针对特定的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。
必须提醒的是，这个操作是不可逆的。如果写入的值不是数字，或者超出了内核允许的范围，写入会失败，而且没有任何提示信息。如果写对了，那就立刻生效，完全不用重启进程，这倒是很实用。
话说回来，三种方法各有各的适用场景。生产环境里，通常都是用户级永久配置打底，再给重要的服务单独设限，偶尔遇到突发情况就用在线调整来兜底。把这套组合拳练熟了，面对高并发场景时心里就踏实多了。