SQL Server 2014/2016 (Win2K12R2) 和 Winsock 限制 - 如何应对？
Phi*_* P. 5 sql-server network windows-server connectivity
我们遇到了与 SQL Server 的连接问题，经过一周的深入研究后，我能够将其确定为 Winsock 限制。这是描述：
- 我们在 Windows Server 2012 R2 上运行了 SQL Server 2014（和 2016）Ent 安装。虚拟化与非虚拟化。我们在两种环境中都观察到了这个问题。
- 客户端不使用连接池（请不要建议打开它，这是问题的根源，我知道，但我对此无能为力）
- 客户端以极高的速度创建和关闭新连接：通常，单个客户端每秒关闭/打开 1500 个连接。每个 SQL Server 有 20-25 个客户端同时执行此操作。
现在，在工作日的某些时间点，我们会遇到流量突发，这实质上使新连接速率飙升至每秒 2500-3500 次连接尝试，并持续大约 2-3 秒。
这就是乐趣开始的时候：客户端在相同的 2-3 秒突发期间收到连接错误。
这就是我们在所有这些连接尝试的网络跟踪中看到的：
我们已经确认和所做的：
- 这不是端口耗尽，无论是在服务器上还是在客户端上。
- 这不是SQL Server 工作线程耗尽。以下是演示它的图表：
- 这是不是一个
TIME_WAIT问题，由客户以前的连接是优雅与关闭FIN, ACK-ACK-FIN, ACK-ACK序列。 - 连接未到达 SQL Server 并被 Winsock 拒绝。这是一个演示它的 PerfMon 图：
- 我们尝试调整 NIC 设置和 Windows TCP/IP 功能设置（RSS、TSO、缩放窗口 - 启用/禁用），但没有解决问题。
- 它不是SYN 攻击保护。我们收集了一个
netsh跟踪，没有迹象表明进入 SYN 洪水攻击保护模式。 - 硬件资源应该不是问题。我们甚至在具有 2TB RAM 的 72 核 / 144 线程 4 插槽盒子上也看到了这个问题。
在 SQL Server 2005 之前，我们能够使用注册表调整积压窗口（我指的是这些说明）。现在我们没有这种能力。
我在上面链接的同一份文件说：
从 SQL Server 2005 开始，网络库将 SOMAXCONN 值作为积压设置传递给
listenAPI。SOMAXCONN 允许 Winsock 提供程序为此设置设置最大合理值。
我的理解是它是根据max connections设置发生的。我们0在 SQL Server 中将其配置为（无限制）。
值得一提的是，当我们遇到问题时，我们确实观察到网络流量（通过网络接口发送/接收的字节数）下降。虽然之前/之后没有增加流量：
那么，问题来了：我们能做些什么来解决这个问题？或者我们实际上达到了 Winsock 的极限？
此处提供的信息使得连接看起来可能由于 TCP 积压队列充满了部分打开的连接而被拒绝。我要求人们在这种情况下仔细检查的另一项是 MPP（内存压力保护）要么全局禁用，要么针对 SQL Server 侦听器端口禁用。
正如您所指出的，SOMAXCONN 是打开 SQL Server 侦听套接字时传入的值，用于给出积压队列的队列深度。不幸的是，您可能已经意识到，在 Windows Server 2019 之前，SOMAXCONN 并未向管理员公开或配置，而是由 Windows 设置为“合理值”。尽管我没有看到有关 Windows 如何确定该值的文档，但我想它会随着系统 RAM 的增加而增加。CPU 数量也可能发挥作用。
探索是否是充满部分打开连接的 TCP 积压队列的一种方法是计算 SYN Received 状态的连接数。
例如，以下 powershell 将给出每个状态（LocalPort、OwningProcess）的连接计数。
Get-NetTCPConnection | Group-Object -Property LocalPort, OwningProcess, State | Select -Property Name, Count | Sort Name
不幸的是，虽然连接计数的趋势会有所帮助，但如果不了解 SOMAXCONN，它可能不是确定的。
不幸的是，Windows 在“netstat -s”输出中不提供 TCPExt 统计信息；“为胚胎 SYN_RECV 套接字接收到的重置”在这里可能特别有用。
如果不知道系统上 SOMAXCONN 的公式或结果值，就很难知道多少 RAM 会导致更高的 SOMAXCONN 值以及部分打开的连接有更多的喘息空间。您提到具有 2TB RAM 的系统遇到类似的连接失败，很可能您不会获得比该值更大的 SOMAXCONN 值。
如果无法将连接突发限制在较低的最大值，那么唯一具有合理信心的干预措施就是尝试加快整个过程中的连接速度。消除对调页空间的任何使用（如果存在）会有所帮助。在虚拟机中，CPU 或内存的超额订阅可能会造成损害（在连接突发期间减慢连接完成速度）。在某些情况下，RSS 可以提供帮助，但您注意到已经尝试过了。WFP 过滤器（Windows 过滤平台），例如防病毒和反恶意软件，可能会增加连接完成的开销；因此，世界粮食计划署正在使用的任何过滤器都值得审查。
使用高性能电源计划而不是平衡电源计划。如果目标服务器上的一段低活动时间后立即出现连接突发，CPU 将开始以较低的时钟速度完成部分打开的连接，这可能会导致完全积压队列，然后连接被拒绝。