python之线程正在为 Amazon 服务的 TCP 请求留下打开的文件

我们正在使用 Amazon Elastic Beanstalk 的 64 位 Python 容器在 Amazon Elastic Beanstalk 中运行一个应用程序。此应用程序生成线程，允许它们存活一定时间，然后在任意时间段内迭代相同模式之前关闭它们。

然后，这些线程中的每一个都会在 Unix 系统中创建一些文件 - 使用带有 FileHandler 的日志记录模块创建的日志文件以及与 SQS、EC2、Cloudwatch、Autoscale 和 S3 的各种连接 - 所有这些都是使用 boto 模块完成的。这些连接创建的 TCP 文件可以在以下结果中识别:

lsof -p {process-id} 

当线程结束时，我们移除 FileHandler 并关闭记录器。我们还明确关闭了使用 boto 建立的每个连接。在任何可能的情况下，我们都会使用 with 语法创建连接或文件，以便之后(希望)可以处理任何资源。

然而，我们发现在线程终止后，仍有一些 TCP 请求作为打开的文件在系统上挥之不去 - 处于 CLOSE_WAIT 状态。这不是立即出现的问题，但最终系统上打开的文件数量超过了 /etc/security/limits.conf 中设置的限制，Python 脚本因此停止执行。

目前，我们通过间歇性地调用 GDB 并指示它关闭我们已确定为陈旧的任何处理程序来掩盖自己，但这种解决方案缺乏优雅，并且忽略了真正的问题，即这些 TCP 打开的文件继续存在。

除了为我提供的close() 连接选项之外，是否还有我遗漏的模式？

请您参考如下方法:

我在 boto 2.3.0 的 CLOSE_WAIT 状态下发现套接字存在同样的问题。原因是连接设置如下:

import boto.ec2 
conn = boto.ec2.connect_to_region("eu-west-1") 

它会首先打开一个连接来查找所有区域，然后打开到给定区域的第二个连接。但第一个连接从未关闭。可以通过 boto.connect_ec2_endpoint(...) 或使用 boto >= 2.7.0 手动设置 ec2 连接 使用静态区域列表的地方。