1

该解决方案是一个 ASP.NET MVC 应用程序,使用托管在 IIS 中的 E/F,在 Hyper-V 环境中托管的 Windows Server 2012 R2 标准 VM 上。同一台 VM 正在运行 SQL Server 2012。

托管环境托管了 30 个其他解决方案,并且有大量可用磁盘空间,并且托管环境或 VM 没有已知的磁盘问题(chkdsk 和 sfc 已在 VM 上运行,未报告任何问题)。

问题是解决方案/服务器在 5-1 分钟的短时间内停止工作,并且每次我们看到来自 ESENT 的事件 ID 508/533 以及有关写入“C:\Windows\system32\LogFiles\Sum”的消息时。

在 sqlsvr 中看到了类似的消息,但通过授予每个人对 C:\Windows\system32\LogFiles\Sum 的所有权限来解决这个问题。

当问题仍然存在时,它会影响整个 VM,有时甚至无法通过远程桌面连接。

当问题发生时,我们已经看到大量打开的 SQL Server 连接,在为特定 Web API 方法引入缓存之前,我们实际上能够清空 SQL Server 连接池。以防万一我们将连接池从 100 个连接更改为 200 个连接,即使自从我们引入缓存以来我们还没有看到这个特殊问题。

所有 DbContext 实例都通过“使用”、ApiController.Dispose 覆盖或 Controller.Dispose 覆盖进行处置,并且仅使用一个 SqlConnection(用于日志记录系统)。

我怀疑问题不在解决方案范围内,并且 SQL Server 连接数过多与 SQL Server 无法写入磁盘的事实有关。

以下是最近三个“故障”的一些 Windows 事件日志摘录,其中包含有关问题之前和服务器自动恢复之后的 Web 请求数量的一些附加信息。

有什么建议么?

问题
前 10 分钟内的 Web 请求:1399 服务器恢复后前 10 分钟内的 Web 请求:1630

18-03-2015 20:07:20 833 MSSQLSERVER SQL Server 在文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ 上遇到 1 次 I/O 请求需要超过 15 秒才能完成数据库 [Xxx] (5) 中的 MSSQL\DATA\Xxx.mdf]。操作系统文件句柄是 0x0000000000000A7C。最近的long I/O的偏移量是:0x000003e104e000

18-03-2015 20:07:40 833 MSSQLSERVER SQL Server 在文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ 上遇到 1 次 I/O 请求的发生时间超过 15 秒数据库 [Xxx] (5) 中的 MSSQL\DATA\Xxx_log.ldf]。操作系统文件句柄为 0x0000000000000A8C。最近一次long I/O的偏移量为:0x0000007f203000

18-03-2015 20:08:16 533 ESENT svchost (1740) 请求写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log”的偏移量 1806336 (0x00000000001b9000) 为 4096 (0x00001000)字节未完成 36 秒。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

18-03-2015 20:17:14 508 ESENT svchost (1740) 请求写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log”的偏移量 1806336 (0x00000000001b9000) 为 4096 (0x00001000) bytes 成功,但操作系统需要异常长的时间(36 秒)才能提供服务。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

问题
前 10 分钟内的 Web 请求:服务器恢复后前 10 分钟内的 696 个 Web 请求:614

19-03-2015 01:17:19 533 ESENT svchost (1740) 请求在偏移量 3067904 (0x00000000002ed000) 处写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log” 4096 (0x00001000)字节未完成 36 秒。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

19-03-2015 01:33:02 508 ESENT svchost (1740) 请求在偏移量 3067904 (0x00000000002ed000) 处写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log” 4096 (0x00001000)字节成功,但操作系统花费了异常长的时间(983 秒)来提供服务。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

19-03-2015 01:33:03 833 MSSQLSERVER SQL Server 在文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ 上遇到 5 次 I/O 请求的发生时间超过 15 秒数据库 [Xxx] (5) 中的 MSSQL\DATA\Xxx_log.ldf]。操作系统文件句柄为 0x0000000000000A8C。最近的long I/O的偏移量是:0x000000a389d000

问题
前 10 分钟内的 Web 请求:服务器恢复后前 10 分钟内的 555 个 Web 请求:784

19-03-2015 03:33:51 833 MSSQLSERVER SQL Server 在文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ 上遇到 1 次 I/O 请求需要超过 15 秒才能完成数据库 [Xxx] (5) 中的 MSSQL\DATA\Xxx_log.ldf]。操作系统文件句柄为 0x0000000000000A8C。最近的long I/O的偏移量是:0x000000aa95f000

19-03-2015 03:40:48 533 ESENT svchost (1740) 请求写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log”的偏移量 3846144 (0x00000000003ab000) 为 4096 (0x00001000)字节未完成 36 秒。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

19-03-2015 03:40:48 833 MSSQLSERVER SQL Server 在文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ 上遇到 1 次 I/O 请求需要超过 15 秒才能完成数据库 [msdb] (4) 中的 MSSQL\DATA\MSDBLog.ldf]。操作系统文件句柄为 0x0000000000000A90。最近的long I/O的偏移量为:0x00000000108000

19-03-2015 03:40:49 508 ESENT svchost (1740) 请求在偏移 3846144 (0x00000000003ab000) 处写入文件“C:\Windows\system32\LogFiles\Sum\Svc.log” 4096 (0x00001000) bytes 成功,但操作系统需要异常长的时间(36 秒)才能提供服务。此问题可能是由于硬件故障。请联系您的硬件供应商以获得诊断问题的进一步帮助。

19-03-2015 03:40:49 17894 MSSQLSERVER Dispatcher (0x1a88) from dispatcher pool 'XE Engine main dispatcher pool' Worker 0x00000000F03B8160 在节点 0 上似乎没有屈服。大约使用的 CPU:内核 0 毫秒,用户 0 毫秒,间隔:336140。

4

2 回答 2

1

磁盘 I/O 问题是我最初的想法,但“有趣”的是它实际上从未在高峰时段发生过,而且高峰时段的服务器在 CPU 或磁盘 I/O 上没有压力。

我找不到任何 VM 磁盘错误。我无法访问托管环境,但我被告知没有磁盘问题。托管环境正在执行 VM 备份,如果这是问题所在,则无需执行任何操作,因为这是必需的。我可能会尝试将 VM 移动到另一个磁盘,但我不知道这是否可能。

目前我们已经在虚拟机上设置了一些详细的磁盘 I/O 监控,希望这会给我们一些关于问题的信息,但我对此表示怀疑。

也许虚拟机只是“生病”了,下一步可能是从头开始创建一个新的……</p>

于 2015-03-21T10:45:42.463 回答
0

听起来您的磁盘只是简单地过载,因为 I/O 需要很长时间。理想情况下,它们应该花费大约 10 毫秒。相反,他们占用了 1000 倍以上的时间。

但是,由于您是在 VM 中运行,因此跟踪问题可能会更加棘手。是由于虚拟机或主机上的 I/O 负载造成的吗?您的 VM 磁盘可能与主机的其他 I/O 负载共享。

您可以将数据库移动到 VM 中的不同卷,托管在主机的不同物理轴上吗?

另一种可能性是底层存储坏了,底层硬件正在重试 I/O。

-马丁

于 2015-03-20T14:49:41.823 回答