新增应用服务器,数据库服务器,间歇性半秒延迟



我在新的生产环境中遇到了间歇性的性能问题。我们已经搬到了一个数据中心,并有一个新的数据库服务器和一个新的应用程序服务器。当问题开始时,我的一些查询开始运行得几乎慢了半秒。我的所有查询都使用存储过程。并非所有人都受到此问题的影响,但它始终是相同的子集。重置我的 IIS 应用程序后,此问题往往会消失。所有查询都通过同一数据层运行。 我已经使用 perfmon 监视了应用程序服务器上的应用程序池,它没有显示任何故障。 我已经检查了数据库上的sys.dm_exec_query_stats,它显示进程运行速度很快(几十毫秒)。 下面是运行所有查询的代码。

Public Function ExecStoredProcCmd(ByVal SQLCmd As SqlCommand) As DataSet
Dim daAdapter As New SqlDataAdapter(SQLCmd)
Dim dsReturn As New DataSet
Dim start As Date
Try
Dim c = GetOpenConnection()
Using c
Using SQLCmd
SQLCmd.Connection = c
SQLCmd.CommandType = CommandType.StoredProcedure
'    PGF.Logging.LogMessage("cDataAccess.ExecStoredProcCmd " & SQLCmd.Connection.ConnectionString)
start = Date.Now
daAdapter.Fill(dsReturn)
Return dsReturn
End Using
End Using
Catch ex As Exception
HandleError(ex)
Throw
Finally
Dim ts = Date.Now - start
If ts.TotalMilliseconds > 250 Then
PGF.Logging.LogPerformance("ExecStoredProcCmd:" & SQLCmd.CommandText, ts.TotalMilliseconds, 1)
End If
End Try
End Function

记录的任何内容都不会低于 490 毫秒(超过 250 毫秒)。

什么会导致通常在 10 到 20 毫秒内运行的存储进程需要额外的半秒?

我应该在哪里查找此错误?

编辑 我一直在比较 sql 探查器跟踪。在测试环境中,慢速进程大约有 40 次读取,零次写入。 在生产环境中,当问题发生时,进程显示大约 8 次读取和零次写入,持续时间为零!最大的区别在于审核注销时间,prod 中的持续时间为 506,我想这是我的问题,因为在测试中显示为零。

这是缓慢的过程。

SELECT cr.[CustomerRevisionID]
,cr.[CustomerID]
,cr.[ClientProducerRevisionID]
,c.FirstName CustomerFirstName
,c.MiddleName CustomerMiddleName
,c.LastName CustomerLastName
,c.CompanyName CustomerCompanyName
,c.contact CustomerCareOf
,Null CustomerRef
,1 CustomerNameFormat
,Null Verification
FROM [dbo].[PGFT_CustomerRevision] cr
JOIN PGF_External.Customer.CustomerMaster c on c.emscustomerID = cr.customerID
WHERE [CustomerRevisionID] = @CustomerRevisionID

编辑 2 我在SQL服务器跟踪中注意到,当它很快时,进程都在同一个SPID上执行,当它很慢时,它们是不同的SPID

编辑 3 当我查询 sys.sysprocesses 时,当它很慢时,我看到为每个查询创建新行。仍然不知道如何解决它。

我在客户现场有这些完全相同的症状。在与他们的基础架构团队进行了大量指责之后,问题竟然是 VMWare 错误,该错误引入了半秒的网络延迟,如本文所述。以下是 kb 文章的摘录(强调我的):

症状

您注意到某些客户端/服务器工作负载的性能下降。 数据包比应用程序中的预期到达时间最多有 0.5 秒的延迟。

在以下情况下会出现此问题:

  • 客户机操作系统是 Windows Server 2012、Windows 8 或更高版本。

  • 虚拟机与硬件版本 11/ESXi 6.0 兼容。

  • 虚拟网卡为 vmxnet3,驱动程序版本为 1.6.6.0 及更高版本。

  • 接收方合并 (RSC) 功能在全局和 vmxnet3 适配器上启用。

  • 在以下情况下,此问题更为普遍:

    • 运行基于 Microsoft/TDS 的工作负载
    • 使用巨型帧
    • 客户端和服务器位于两个不同的主机上

原因

根据不同的物理网卡和工作负载特征(如芯片组、合并设置和数据包到达速率),RSC 卸载的某些数据包可能会遇到额外的延迟。聚合多个数据包时,ESXi 将仅保留推送标志(PSH 标志),前提是在要合并的第一个数据包上设置了推送标志(PSH 标志)。如果第一个数据包未设置 PSH 标志,但后续数据包设置了 PSH 标志,则最终合并的数据包将不会设置该标志,因此可能不会立即传递到应用程序。

分辨率

此问题已在 ESXi 6.0 Update 2 中得到解决,可在 VMware Downloads 中找到。

最新更新