Cloud Foundry中Too many open files错误排查求助

一、Jar文件大量打开记录的排查 #

• 先确认lsof中Jar文件的记录类型：查看输出的TYPE列，若为REG（普通文件）且MODE包含r--，这类记录多数是类加载时打开的文件句柄，但191条记录不一定对应每个请求。重点排查以下方向：
  • 类加载器重复创建：多租户场景下若为每个租户单独初始化类加载器，会重复加载Jar文件并占用句柄。检查Spring配置或第三方多租户框架的类加载策略，是否存在不必要的类加载器隔离逻辑。
  • Tomcat资源扫描配置：Tomcat的JarScanner若配置不合理（如开启scanAllDirectories或扫描间隔过短），会频繁扫描Jar文件导致重复打开。检查conf/context.xml中的JarScanner参数，调整扫描范围和频率。
  • Cloud Foundry容器特性：CF容器的临时文件系统在实例重启、缩放时，若应用未正确释放Jar句柄，可能积累无效记录。可重启单个实例对比lsof结果，确认是否为实例生命周期内的句柄泄漏。

二、Socket连接CLOSE_WAIT状态的排查 #

CLOSE_WAIT表示对方已关闭连接，但本地未调用close()释放句柄，需从连接管理逻辑入手：

• 数据库连接池异常回收：
  • 检查testOnBorrow、testOnReturn、testWhileIdle配置，若连接验证失败时未触发连接销毁，会残留CLOSE_WAIT状态的Socket。
  • 确认removeAbandonedTimeout和removeAbandoned是否启用，若连接被标记为废弃但未及时关闭，会堆积无效连接。
• 微服务调用的连接管理：
  • 检查HTTP客户端（如RestTemplate、Feign）的连接池配置，是否设置了maxIdleTime或connectionTimeout，确保闲置连接被主动回收。
  • 排查异常场景下的连接处理：调用微服务抛出异常时，是否未关闭HTTP连接或释放响应流。
• TCP参数调整：查看容器的net.ipv4.tcp_fin_timeout参数（默认60秒），若CLOSE_WAIT连接堆积，可尝试缩短该超时时间（需确认CF平台是否允许自定义内核参数）。

三、getConnection超时与Broken Pipe问题的排查 #

• max wait配置未生效：Tomcat JDBC的maxWait仅控制从连接池获取可用连接的等待时间，连接池尝试创建新连接或验证旧连接时的耗时不受该参数限制：
  • 核对initialSize、maxActive配置，300个租户×8个连接=2400，是否超过数据库最大连接数，导致创建连接阻塞。
  • 检查validationTimeout参数，若未设置，验证连接时遇到Broken Pipe可能触发TCP层的长超时（甚至10分钟），需将validationTimeout设为小于maxWait的值（如5秒）。
• Broken Pipe后Socket未关闭：Broken Pipe表示连接已被对方关闭，正常情况下Tomcat JDBC应自动销毁连接并关闭Socket。若仍存在CLOSE_WAIT：
  • 开启org.apache.tomcat.jdbc.pool的DEBUG日志，查看borrowConnection遇到Broken Pipe后的处理流程，确认是否调用了close()方法。
  • 检查数据库侧的闲置连接超时配置，若数据库主动关闭闲置连接，但连接池未通过testWhileIdle检测到，会导致失效连接被复用，触发Broken Pipe。

四、Too many open files的根源确认 #

• 系统句柄限制：CF容器默认文件句柄限制通常为1024或4096，2400个数据库连接+Jar句柄+微服务连接可能超出上限。通过ulimit -n查看容器句柄上限，若不足，可在manifest.yml中配置limits: { file_descriptors: 65535 }调整。
• 句柄泄漏定位：
  • 用jstack <pid>获取线程栈，结合lsof -p <pid> | grep REG中的FD列，找到持有Jar文件句柄的线程，定位类加载或资源加载的异常逻辑。
  • 用netstat -anp | grep CLOSE_WAIT找到对应端口和进程，结合应用日志排查该连接对应的业务逻辑，确认是否存在未关闭连接的场景。

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