SageMaker调用Athena遇[Errno 24] Too many open files错误求助

错误本质定位 #

urllib3.exceptions.SSLError: [Errno 24] Too many open files 是表象，核心是系统文件描述符耗尽——每个SSL连接、文件句柄、网络套接字都会占用一个文件描述符，当累积数量超过系统限制时就会触发该错误。

具体解决步骤 #

1. 调整SageMaker实例的文件描述符限制 #

• 先查看当前实例的文件描述符限制：

  ulimit -n
  

  SageMaker默认软限制通常为1024或4096，不足以支撑49+批次的连续查询。
• 临时提升限制：在脚本启动前执行命令（可添加到SageMaker estimator的entry_point开头，或通过container_arguments传递）：

  ulimit -n 65536
  

  若仍不够，可尝试更高值（如1048576），只要不超过实例内核允许的硬限制。

2. 排查代码中的资源泄漏 #

• 复用Athena客户端实例：不要在每个批次循环中新建boto3.client('athena')，全局初始化一次客户端即可——重复创建客户端会累积未释放的连接套接字，占用文件描述符。
• 确保文件句柄正确关闭：处理Athena查询结果（如读取S3上的CSV文件）时，务必用with语句自动关闭文件，避免手动open()后未调用close()：

  with open('s3://your-bucket/query-result.csv', 'r') as f:
      # 处理文件内容
  

• 配置连接池大小：给boto3客户端设置合理的连接池上限，避免连接数过多：

  from botocore.config import Config
  import boto3
  
  config = Config(max_pool_connections=50)  # 根据批次频率调整
  athena_client = boto3.client('athena', config=config)
  

• 清理无用资源：每批处理完成后，将不再使用的大对象（如DataFrame、查询结果集）赋值为None，主动释放引用。

3. 强制资源回收 #

每批处理结束后，触发Python垃圾回收，主动清理未释放的资源：

import gc
gc.collect()

4. 优化批次查询逻辑 #

• 减少小批量查询的频次：如果时间窗口允许，适当调整批次大小（在内存承受范围内），降低总查询次数，减少连接开销。
• 使用Athena分页查询：通过get_query_results的NextToken参数分页获取结果，避免一次性加载大量数据导致的资源占用。

5. 排查环境变量与依赖变化 #

• 检查依赖包版本：对比三周前的环境，查看boto3、urllib3是否有版本更新，若有，尝试回退到之前的稳定版本：

  pip install boto3==x.x.x urllib3==y.y.y
  

• 确认SageMaker容器镜像是否变更：若使用自定义镜像，检查是否有环境配置（如文件描述符限制）的改动。

内容的提问来源于stack exchange，提问作者Saif Ali Khan