2
我在Ubuntu 16.04机器上运行数据采集系统。它部署在远程站点，所以我改变物理配置的能力是有限的。我们确实有一个现场的人员能够通过配置执行简单的测试。Python套接字连接在Ubuntu上每9个连接有一秒延迟16.04
我们正在运行一个python脚本来做数据采集。但是，我们注意到，在高数据速率下，我们在数据缓冲区中出现了奇怪的备份。几个小时的调试后，我们能够缩小问题下到下面的测试案例：
for i in xrange(500):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('1.2.3.4', 5678))
sock.close()
当上面的代码执行大多数样品执行几乎在瞬间，但每一个样品9日恰好需要一秒钟执行。奇怪的是，实际采集数据时，时间要短得多 - 在一次测试中大约需要650ms左右，并且在毛刺采样之前有更多连接成功（在这种情况下，毛刺采样只需要650ms间隔的〜400ms）。下面是两个实例的连接延迟与时间的关系图。轴是以秒为单位）。
Latency between connections. connect-and-close in blue, system under load in red.
这是我们尝试调试的一个子集，以及是否问题依然存在或者没有在每种情况下。简洁的道歉;如果有任何不清楚的地方，我很乐意提供后续信息。
- 数据采集与netcat的：工作2台的Ubuntu 14.04机器之间
- 运行Python脚本（针对NC监听器，不能与数据源来测试）：工作
- 连接到运行一个netcat的监听器的另一台计算机，代替数据源，从采集计算机：问题仍然存在
- 呼叫
shutdown()close()之前：问题仍然存在 - 使用
asyncore运行服务器尝试：问题仍然存在 - 试图在线程打开插座：问题仍然存在
- 已切换各种
net.ipv4.tcp_*内核参数：问题仍然存在
从上面的，我已经能够辨别的唯一一致的是，这个特定的机器上运行的蟒蛇遇到这个问题。我还没有机会在另一个Ubuntu 16.04（或任何其他4.x内核）上测试此功能，所以我不知道它是否与网络堆栈中的更改有关。我会继续运行各种测试来尝试诊断这个问题，但任何想法都会受到赞赏！
更新：
的ulimit -a结果（没有跳出我的异常）。
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 40
file size (blocks, -f) unlimited
pending signals (-i) 32053
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 32053
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
我将尽快运行TIME_WAIT测试并发布结果。我希望运行的另一个测试是使用strace运行netcat和python调用，以查看套接字和连接的参数是否不同。
请检查'ulimit'。假设远程服务器具有处理所有传入连接的能力，我怀疑必须有一些限制因素可用于连接数量。另外，使用netcat来监视TIME_WAIT套接字，可能是因为连接没有正确关闭。如果是这种情况，请尝试：'sock.setsockopt（socket.SOL_SOCKET，socket.SO_REUSEADDR，1）'。请让我知道进度:) – purrogrammer
什么是侦听队列值？在服务器端？当它填满时，由客户端发送的syn将被丢弃，并发生tcp重新传输。这个默认值是3秒（可能是你的系统调整为1秒），为了确认，你应该捕获tcpdump并验证 – VenkatC