Aspstate SQL Server数据库镜像高IO

我们目前有aspstate数据库镜像的问题，因为我们每天有大约10,000名在线用户在线，aspstate数据库在编写和传递给镜像时过于沉重，镜像的驱动器在IO上非常高，并且由于在镜像上写入数据的延迟而导致两个服务器不可访问。我们使用的是SQL Server 2012标准，因此不采用异步模式。Aspstate SQL Server数据库镜像高IO

我们正在使用EBS支持的卷和1000IOPS的Amazon EC2实例上运行SQL Server，在您的视图中是否足够？由于我们似乎有非常顺利的时间，我们已经有超过15,000名在线用户，而其他时间只有10,000名用户在线，而且我们在镜像（备份服务器而非主服务器）上存在磁盘队列长度问题。

当磁盘队列长度增加时，该原理可以以10-20mbps的恒定值写入aspstate.mdf文件。

我们打算将IOPS提高到2000，同时我们必须禁用镜像，但是您是否期待这一点，并且有人曾经处理过此类卷？

问候

利亚姆 Resource monitor Performance monitor Cloudwatch

来源

2014-09-25 Liam Wheldon

高交易工作负载一样ASPState的瓶颈不是数据文件，但事务日志。在同步镜像的情况下，镜像网络和同步提交都会引入额外的延迟。如果您有大量APSState请求，则此延迟将不可接受。请记住，除非在启用会话状态的情况下另行指定，否则每个ASP.NET页面请求都需要对会话状态行进行2次更新。因此，如果您有10,000名活跃用户每15秒钟点击一次，那么每秒需要大约1,300个I/O才能在每个数据库上单独进行事务日志写入。

如果您必须有会话状态的高可用性，我建议故障切换集群以消除网络延迟。您也可以考虑通过为不需要会话状态的页面指定只读或无指令来调整会话状态。如果您需要支持大量用户，请考虑使用内存中会话状态解决方案而不是现成的ASPSession状态数据库。另请记住，会话状态数据是暂时的，因此您可以放弃持久性。

来源

2014-09-25 13:15:13

嗨Dan，谢谢你的回复。日志文件在主服务器上写得很好，并且根本不写在镜像服务器上（如预期的那样），但是在这种情况下问题是数据文件，因为它是磁盘队列长度问题的镜像服务器而非主服务器来自原理的日志用于不断写入镜像的mdata文件。但令我困惑的是，如何将主要日志文件写入到镜像数据（必须与镜像相同），但是只有镜像在两个数据和日志分区上具有相同的IOPS时才挣扎？ – 2014-09-25 14:00:02

@Liam Wheldon，不知道你的意思是什么都不写在镜子上（二级）。日志记录写在主数据和次数据之前。 – 2014-09-26 00:37:12

嗨Dan，我添加了屏幕截图来展示我如何相信mdf直接写在镜子上。感谢您坚持使用这个:-) – 2014-09-26 07:51:08

Aspstate SQL Server数据库镜像高IO

回答

相关问题