我们的ASP.Net网站使用SQL Server作为会话状态提供程序。 我们目前在SQL Server 2005上托pipe数据库，因为它在2008 R2上不能很好地运行。 我们想知道为什么，以及如何解决这个问题。
硬件设置我们当前的会话状态服务器具有SQL Server 2005，并在单个本地磁盘上托pipe文件。 这是我们服务最好的服务器之一，因为它为我们提供了很好的服务，我们从来没有觉得有必要升级它。 该数据库大约2 GB持有6000会议。 （会话有点大，但我们需要它。）我们有另一台服务器与SQL Server 2008 R2有一个更快的CPU和更多的RAM。 编辑：我骗了更快的驱动器。 较旧的服务器有一个15K 36GB SAS驱动器。 新的服务器有15K驱动器的RAID 1镜像和136GB的可用空间。
情况有一天，我们有一个巨大的stream量激增。 SQL Server上的事务日志增长将服务器冻结10秒，只允许几分钟内完成几个请求。 所以我们用ASPState加载新的服务器，数据和日志文件非常大，并将所有的应用程序指向新的服务器。 大约5分钟的时间内，它可以很好地工作，然后CPU使用率跳到标准版可以使用的16个内核的50％，并一次冻结10秒。 这些文件不logging任何autogrowth事件。 磁盘队列很好，很低。 RAM使用率低。
旧服务器上的CPU使用率从来没有高于5％。 新服务器上发生了什么？
另外，我想听听在SQL Server 2008 R2上运行的ASP.NET会话状态服务器的成功案例，平均写入负载为30MB /秒，突发速率高达200MB /秒。
SQL Server 2005的第一台服务器正常运行，因此增加了大量的事务日志。 有一些技巧可以用来提高mdf文件的文件增长速度，但不能用于ldf。
根据上面的信息，我不确定要告诉您关于第二台服务器的信息。 但是，磁盘队列可能不是您要查找的指标。 您可能需要Perfmon计数器逻辑磁盘：平均值。 Disk sec / Write或其等价物，ldfs的最佳值（平均值）为5ms或以下。
我会猜测，基于“更快的硬盘”，你没有使用RAID。 尽pipe有磁盘队列号，但是您仍然可能遇到磁盘写入压力。 您也可能遇到locking或locking等待。
这里有一个查询可以帮助诊断等待：
http://www.brentozar.com/responder/triage-wait-stats-in-sql-server/