多个 tcp 套接字，一个停止答案

【问题标题】：Multiple tcp sockets, one stalled多个 tcp 套接字，一个停止
【发布时间】：2015-10-30 07:14:30
【问题描述】：

我正在尝试从哪里开始了解可能导致套接字停止的原因，并且希望你们中的任何人都可以提供任何见解。

因此，服务器是运行 Windows 2012 的现代双套接字至强（2 x 6 核 @ 3.5 ghz）。在单个进程中，有 6 个具有默认选项的阻塞 tcp 套接字，每个都在自己的线程上运行（未指定 numa/core）。其中 5 个连接到同一个远程服务器并接收非常重的负载（每秒数十万个约 75 字节的小消息）。最后一个套接字连接到不同的服务器，管理消息的发送/接收负载非常轻。

我遇到的问题是管理消息套接字中的 5 秒停顿。对套接字的多次发送调用成功返回，但是没有从远程服务器收到任何内容（应该在毫秒内收到协议确认）或远程管理服务器收到 5 秒。就好像那个插座刚刚关了一会儿。 5秒的失速过去后，所有的ack都来了，之后一切正常。在此期间，其他套接字接收到的消息数量比正常情况多得多，但是没有任何中断或停止的迹象，因为数据日志没有显示任何异常（光记录，可能是 500 消息/秒）。

据我了解，套接字发送调用并不能确保数据已经在线上输出，只是成功传输到 tcp 堆栈。因此，我试图了解可能发生的不同情况，这些情况会导致管理套接字上的 5 秒停顿。是否有可能由于接收到大量数据，tcp 堆栈基本上不堪重负，并优先考虑那些使用最频繁的套接字？还有哪些其他情况可能导致这种情况？

谢谢！

【问题讨论】：

服务器的 SSD 是否快满了？
不，它非常简单且全新。 23gb 使用 65gb 分区。 2 磁盘 150gb 板载 raid1。我也考虑过磁盘，但记录器在它自己的线程中，并且在停顿期间没有任何打嗝。
欢迎使用 TCP/IP。延迟的可能性几乎是无限的。我不是在开玩笑。 TCP 保证交付，但不保证何时交付。不要将它用于时间紧迫的消息。由于拥塞控制导致的一些丢失数据包的重传延迟是最有可能的候选者。
可以想象，内核忙于处理由入站数据引起的中断，以至于它无法处理出站数据，这比中断处理的优先级低。或者 admin peer 读取速度很慢，所以它的接收窗口被关闭了，所以出站数据根本无法传输。
@user4581301，是的，但是 5 秒？从阅读 Windows TCP 传输延迟，据我了解，最大等待时间应该是 200 毫秒。

标签： c++ windows sockets networking tcp

【解决方案1】：

如果套接字每秒接收数十万条 75 字节的消息，则服务器可能在某些资源上处于最大容量。也许不是带宽，就像 100K 消息一样，您可能会消耗大约 10Mbps。但这可能是 CPU 利用率。

你应该使用两个工具来理解你的问题：

perfmon 查看 CPU 利用率（用户和特权https://technet.microsoft.com/en-us/library/aa173932(v=sql.80).aspx）、内存、带宽和磁盘队列长度。您还可以使用 perfmon 检查中断次数和上下文切换。
像 Wireshark 这样的嗅探器，可以查看是否在 TCP 级别传输数据并接收响应。
我要做的其他事情是在发送调用之后以及在负责管理套接字的线程中读取调用之前和之后写一个时间戳。可能是编码问题。

发送调用成功返回并不意味着数据立即发送。在 TCP 中，数据将存储在发送缓冲区中，然后 TCP 堆栈会将数据发送到另一端。

如果您的系统受 CPU 限制（如果这是真的，您可以使用 perfmon 查看），那么您应该注意 @EJP 编写的 cmets，这可能在机器负载过重时发生。使用我提到的工具，您可以查看管理套接字中的接收窗口是否关闭，或者是否只是套接字读取在管理套接字中花费了时间。

【讨论】：