已调整ulimit至1048576，Ignite重启仍报Too many open files异常

我来帮你排查这个问题——你手动执行ulimit -n 1048576修改的只是当前Shell会话的临时限制，但Ignite作为后台服务进程大概率没继承这个设置，这就是为什么你看到ulimit -a显示数值已变，但服务还是启动失败。下面分步骤解决：

1. 配置系统级持久化文件句柄限制 #

临时的ulimit设置重启或切换会话就会失效，需要在系统配置文件中添加持久化规则：

• 编辑/etc/security/limits.conf文件，在末尾添加（替换ignite为运行Ignite的实际用户）：

  ignite soft nofile 1048576
  ignite hard nofile 1048576
  

• 如果/etc/security/limits.d/目录下有其他配置文件，也要确保没有覆盖这个设置。
• 保存配置后，重新登录系统（或重启服务器）让配置生效。

2. 针对systemd管理的Ignite服务额外配置 #

如果Ignite是通过systemd作为服务启动的，systemd会忽略limits.conf的设置，需要单独配置服务文件：

• 找到Ignite的systemd服务文件（通常是/etc/systemd/system/ignite.service或类似路径）
• 在[Service]段添加：

  LimitNOFILE=1048576
  

• 重新加载systemd配置并重启服务：

  systemctl daemon-reload
  systemctl restart ignite
  

3. 验证进程实际生效的限制 #

启动Ignite后，用以下命令验证进程实际能使用的文件句柄数：

# 替换<ignite_pid>为Ignite进程的PID
cat /proc/<ignite_pid>/limits | grep "Open files"

如果输出的Soft Limit和Hard Limit都是1048576，说明限制已经生效；如果不是，检查前面的配置步骤是否遗漏。

4. 额外排查：Ignite自身配置问题 #

如果系统限制已经生效但还是报错，需要检查Ignite的配置：

• 是否配置了大量缓存实例或并发连接？
• 日志配置是否开启了过多的日志文件滚动？
• 是否有第三方插件或扩展占用了额外的文件句柄？

内容的提问来源于stack exchange，提问作者dvlcis