我们在VMware虚拟机中运行SQL Server 2016 SP1的单个实例。它包含4个数据库，每个数据库用于一个不同的应用程序。这些应用程序都位于单独的虚拟服务器上。它们都没有在生产中使用。但是，测试应用程序的人员正在报告性能问题。
这些是服务器的统计信息：
- 128 GB RAM（SQL Server最大110GB内存）
- 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-3ms。在正常使用该应用程序期间，数据库服务器的IO最高写入速度为20MB / s（平均为7-9MB / s）。当我进行压力测试时，最高速度达到5GB / s。
对于我们的ERP系统数据库，缓冲区高速缓存大小为60GB，对于我们的财务软件，为20GB，对于质量保证软件，为1GB，对于文档归档系统，为3GB。
我授予了SQL Server帐户使用即时文件初始化的权利。丝毫没有提高性能。
在正常使用期间，页面预期寿命约为15k +。在预期的重压力测试结束时，该值下降至.05k左右。批处理/秒约为2-8k，具体取决于工作负载。
我会说ERP应用程序写得不好，但是我不能，因为所有应用程序都受影响。即使工作量最少。
但是我无法查明是什么原因造成的。是否有任何提示，提示教程，应用程序，最佳/最差实践文档或其他有关此问题的想法？
这些是来自的结果sp_BlitzFirst：
我跑了600秒。我在工作量很大的应用程序中启动了它。是1/3的时间ASYNC_NETWORK_IO。我还测试与网络连接NTttcp，PsPing，ipferf3，和pathping。没什么不寻常的。响应时间最大3毫秒，平均0.3毫秒。吞吐量约为1000 MB / s。
我的调查总是导致ASYNC_NETWORK_IOwaitstat排名第一。
我们调查了Large-Receive-Offload在VMware 中禁用该功能的结果。我们仍在测试中，但结果似乎不一致。我们的第一个“基准测试”持续了19分钟（最高结果是13分钟，只有当应用程序在具有SQL Server本身的VM上运行时才能实现）。第二个结果是28分钟，这确实很糟糕。
我们的“基准测试”的第一结果是19分钟。哪个好 因为最高的结果是13分钟（仅当应用程序使用SQL Server本身在VM上进行基准测试时才可以实现）。这强烈暗示了一些与网络有关的问题。或VMware配置出现问题。
我目前迷失于使用哪种方法来确定瓶颈。
仅当应用程序在带有SQL Server本身的VM上运行时，才能实现该应用程序的最佳性能。如果该应用程序在任何其他VM或虚拟桌面上执行，则基准测试的持续时间将增加两倍（从13分钟持续时间增加到40分钟或更长）。所有端点（SQL Server的VM，应用程序服务器的VM和虚拟桌面）都使用相同的物理硬件。我们已将所有其他端点移至其他硬件。
编辑：似乎问题又回来了。将节能模式从平衡设置为高性能后，我们实际上大大缩短了响应时间。但是今天，我再次运行了sp_BlitzFirst，并进行了300秒的采样。结果如下：
它显示的ASYNC_NETWORK_IO等待时间比sp_blitzfirst运行的秒数要多。