我需要一个确凿的证据来证明 TIME_WAIT(实际上是很多)是我们一台服务器速度变慢的真正罪魁祸首。服务器托管在 Parallels Baremetal 虚拟化上,实际服务器是虚拟机:具有双 CPU 和 2GB RAM 的 CentOS5。
一周前,我们开始注意到它太慢了,即使在只有几个文件(大约 20 个)的目录上执行“ls”也需要大约 1.5 秒才能显示结果。
我尝试这样做vmstat
,但似乎没有使用它的交换。网络上没有瓶颈。但是运行时top
,您会看到 java 主要占用资源。需要 Java,因为该 VM 是我们的 hudson 服务器。
我的一位同事尝试通过以下方式检查连接
$ vmstat -vatpno
并注意到有很多处于 TIME_WAIT 状态的连接...大约 300+。因此我们尝试应用其中的一些建议这一页特别是 TCP_FIN_TIMEOUT、TCP_KEEPALIVE_INTERVAL 和 TCP_KEEPALIVE_PROBES。 TIME_WAIT 中的连接数有所下降,但仍然在 220 到 280 之间波动(可能是由于不时添加新连接而 TIME_WAIT 中的其他连接尚未“超时”)。也许稍后当我们没有看到任何改进时,我们可以尝试添加 TCP_TW_RECYCLE 和 TCP_TW_REUSE。
现在回到我的主要问题:是否有确凿的证据表明大量 TIME_WAIT'ed 连接会消耗大量 RAM?
答案1
处于 TIME_WAIT 状态的连接只是等待查看是否有任何最后的散乱数据包从另一端通过网络,以便它们不会与另一个连接的数据包混合。实际上并没有做任何与这些数据包有关的东西。因此,TIME_WAIT 连接使用的资源比打开的连接少。
如今配置良好的网络服务器可以处理超过 10,000 个并发连接(请注意,这是 2003 年写的,摩尔定律仍在继续发展)。如果有的话,处于 TIME_WAIT 状态的连接将比打开的连接占用更少的内存,因此 TIME_WAIT 状态下的 300 个连接应该没什么。
有关 TIME_WAIT 的详细信息,请参阅http://tangentsoft.net/wskfaq/articles/debugging-tcp.html和http://developerweb.net/viewtopic.php?id=2941。
同时,我想知道你的磁盘 I/O 使用情况如何。根据我的经验,大量的磁盘 I/O 比大量的 CPU 使用更容易降低 Linux 内核的速度。您可能需要研究iostat
和dstat
工具,看看它们告诉您什么。