排查有关基础网络的 TCP/IP 性能问题
注意
本文包含在由 3 个部分组成的系列中。 可查看 第 1 部分:TCP/IP 性能概述 和第 3 部分:TCP/IP 性能已知问题。
当吞吐量低于给定 基线时,请使用数据包捕获工具进行网络跟踪并检测网络问题。
使用 ctsTraffic 工具分析网络跟踪
下面是如何使用 ctsTraffic 工具分析网络跟踪的示例:
注意
进行网络跟踪可能会导致吞吐量进一步降低。
在客户端和服务器端运行 ctsTraffic 工具。
在服务器上运行以下命令:
CTStraffic -listen:*
在客户端上运行此命令:
CTSTraffic -target:<serverip> -consoleverbosity:3 -connections:4 -iterations:10 -connectionfilename:<filename>.csv
停止客户端和服务器端的网络跟踪。
检查 <文件名>.csv 文件:
- 如果文件中显示了 NetworkErrors 或 ProtocolErrors,请转到下一步。
- 如果未显示任何错误,请停止并放弃网络跟踪。 收集客户端和服务器上的新跟踪。 在步骤 1 中尝试使用越来越多的连接 (
-connections:
) ,直到出现错误。
在<文件名>.csv 文件中查找错误的客户端套接字号,并应用此编号作为筛选器,以检查数据包丢失、数据包重新传输或未从任一终结点启动的 TCP 重置。 拥有此信息后,请联系网络团队寻求帮助。
检查性能监视器日志
检查性能监视器日志,查找在以下情况下已丢弃的数据包:
- 存在错误,但在数据包捕获中未发现问题。
- 原始数据包到达目标,但发送方重新传输相同的数据包,因为接收方没有确认 (ACK) 。
数据包丢弃的原因可能是网络卡驱动程序或处理器无法处理接收器上的传入数据包。 请确保网络卡驱动程序是最新的,并且 RSS/VMMQ 设置正确。 例如,若要在 SQL Server 等服务器上使用更多基本处理器,请将 RSS/VMMQ 自定义为不使用基本处理器,并从下一个物理核心开始处理。
有关详细信息,请参阅 与网络相关的性能计数器。
注意
自定义 RSS/VMMQ 仅用于故障排除,并完全了解操作。
后续步骤
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈