SQL Server 2016 的奇怪性能问题

Question

我们有一个在 VMware 虚拟机中运行的 SQL Server 2016 SP1 实例。它包含 4 个数据库，每个数据库用于不同的应用程序。这些应用程序都在单独的虚拟服务器上。它们都没有在生产中使用。不过，测试应用程序的人报告了性能问题。

这些是服务器的统计信息：

• 128 GB RAM（SQL Server 的最大内存为 110 GB）
• 4 核 @4.6 GHz
• 10 GBit 网络连接
• 所有存储均基于 SSD
• 程序文件、日志文件、数据库文件和 tempdb 位于服务器的不同分区上
• 阿斯达

用户通过基于 C++ 的 ERP 应用程序执行单屏幕访问。

当我ostress使用许多小查询或大查询对 Microsoft 的 SQL Server 进行压力测试时，我获得了最大性能。唯一的限制是客户端，因为他不能足够快地回答。

但是当几乎没有任何用户时，SQL Server 几乎不做任何事情。然而，人们必须永远等待才能在应用程序中保存任何内容。

根据 Paul Randal 的“告诉我它在哪里受到伤害”查询，所有等待事件中有 50% 是ASYNC_NETWORK_IO.

这可能意味着网络问题，或应用程序服务器或客户端的性能问题。他们甚至都没有以最大能力远程使用他们的资源。大多数情况下，所有机器（客户端、应用程序服务器、数据库服务器）上的 CPU 都在 26% 左右。

网络连接的延迟约为 1-3 毫秒。数据库服务器的 IO 在应用程序正常使用期间的最大写入速度为 20MB/s（平均为 7-9MB/s）。当我进行压力测试时，我的速度最高可达 5GB/s。

缓冲区缓存大小为我们的 ERP 系统 DB 为 60GB，我们的财务软件为 20GB，质量保证软件为 1GB，文档归档系统为 3GB。

我授予 SQL Server 帐户使用Instant File Initialization的权利。这丝毫没有提高性能。

在正常使用期间，页面的预期寿命约为 15k+。在重压测试结束时下降到 0.05k 左右，这在意料之中。批次/秒约为 2-8k，具体取决于工作负载。

我会说 ERP 应用程序写得不好，但我不能，因为所有应用程序都受到影响。即使工作量最小。

然而，我无法确定是什么导致了这种情况。是否有任何提示、提示教程、应用程序、最佳/最差实践文档或关于此问题的其他任何想法？

这些是来自sp_BlitzFirst以下方面的结果：

我跑了600秒。我在应用程序的高工作负载期间启动了它。1/3 的时间是ASYNC_NETWORK_IO. 我还测试与网络连接NTttcp，PsPing，ipferf3，和pathping。没什么不寻常的。响应时间最大为 3ms，平均为 0.3ms。吞吐量约为 1000 MB/s。

我的调查总是导致ASYNC_NETWORK_IO成为排名第一的waitstat。

我们调查了Large-Receive-Offload在 VMware中禁用该功能的结果。我们仍在测试，但结果似乎不一致。我们的第一个“基准”导致持续时间为 19 分钟（最高结果是 13 分钟，只有当应用程序在带有 SQL Server 本身的 VM 上运行时才能实现）。第二个结果是 28 分钟，这真的很糟糕。

我们的“基准”的第一个结果是 19 分钟。哪个好。因为最高的结果是 13 分钟（只有当应用程序在 VM 上与 SQL Server 本身进行基准测试时才能实现）。这强烈暗示了一些与网络相关的问题。或者 VMware 配置问题。

我目前不知道使用什么方法来确定瓶颈。

只有当应用程序在带有 SQL Server 本身的 VM 上运行时，才能实现应用程序的最大性能。如果应用程序在任何其他 VM 或虚拟桌面上执行，我们的基准测试持续时间将增加三倍（从 13 分钟持续时间到 40 分钟或更长时间）。所有端点（SQL Server 的 VM、应用服务器的 VM 和虚拟桌面）都使用相同的物理硬件。我们已将所有其他端点移至其他硬件。

编辑：似乎问题又回来了。在将节能模式从平衡模式设置为高性能模式后，我们实际上大幅提高了响应时间。但是今天我再次运行了 sp_BlitzFirst，样本为 300 秒。这是结果：

它显示 ASYNC_NETWORK_IO 的等待时间比 sp_blitzfirst 运行的秒数多。

Answer 1

如果您的主要等待是ASYNC_NETWORK_IO，则问题不在于 SQL Server。这几乎总是由于应用程序瓶颈。我的意思不是应用服务器上的瓶颈，而是应用程序中的瓶颈。

应用程序瓶颈通常是因为 SQL Server 发送数据时逐行处理：

• 应用程序正在从 SQL Server 请求数据
• SQL Server 正在快速发送数据
• 应用程序告诉 SQL Server 在处理每一行时等待
• SQL ServerASYNC_NETWORK_IO在应用程序告诉它等待时记录等待时间

取而代之的是，应用程序需要使用来自 SQL Server 的所有数据，然后逐行进行处理。那时 SQL Server 不在考虑范围内。

sp_BlitzFirst 输出

在LCK_M_S等待不高。30秒样本中只有2秒在它上面，它的平均值只有400ms。这极不可能是问题所在。ASYNC_NETWORK_IO是您在该示例中的最高等待时间。还是应用问题。如果您需要有关这些LCK内容的帮助，我们需要查看所涉及的查询。

即使ASYNC_NETWORK_IO在那个样本中也没有那么糟糕。当等待时间等于或大于样本量时，我的眼睛会变大。那是我钻进去的时候。

你的整个问题是ASYNC_NETWORK_IO。这不是 SQL Server 问题。这是应用程序（在 SQL Server 发送数据时进行逐行处理）、应用程序服务器（您已经说过它很好）或网络（您已经说过网络很好）的问题。所以问题出在应用程序上。C++ 应用程序需要修复。

Answer 2

回答我自己的问题： ASYNC_NETWORK_IO 作为顶级等待类型出现在我们的 SQL Server 上的主要原因energy saving是 Windows 服务器的设置被设置为'balanced'而不是'high performance'. 之后我们与一些 vm ware 管理员交谈，他们都说，这个设置会降低性能。

对此的解决方案是：

• 安装windows服务器时不要安装能源控制
• 通过组策略将所有服务器的节能模式设置为高性能

关于 ASYNC_NETWORK_IO 的所有其他问题/统计数据都与我们的 ERP 应用程序编写不当有关。感谢所有帮助我解决这个问题的人，非常欢迎您提出意见、建议和建议，并且很有帮助！