Question

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

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

lsof -p {process-id}

线程完成后，我们删除FileHandler并关闭记录器。我们还明确关闭了使用boto进行的每个连接。在任何可能的情况下，我们使用with语法创建连接或文件，以便之后可以（希望）处理任何资源。

然而，我们发现，在线程终止后，在CLOSE_WAIT状态下，TCP请求仍然在系统上作为打开文件延迟。这不是一个问题，但最终系统上打开文件的数量超过了/etc/security/limits.conf中设置的限制，并且Python脚本因此而停止执行。

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

除了close()连接提供给我的选项之外，我是否遗漏了某种模式？

Answer 1

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

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

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