5

我运行了一个流量不错的网站（每天大约 100,000 次页面浏览量），但由于 SQL Server 超时错误，该网站偶尔会瘫痪。

当我运行 SQL Profiler 时，我看到一个命令每秒被调用数百次，如下所示：

...
exec dbo.TempGetStateItemExclusive3 @id=N'ilooyuja4bnzodienj3idpni4ed2081b',...
...

我们使用 SQL Server 来存储 ASP.NET 会话状态。以上是为获取给定会话的会话状态而调用的存储过程。它似乎在循环，一遍又一遍地要求相同的 2 或 3 个会话。

我找到了一个看起来很有希望的热修复程序，它似乎可以解决这个确切的情况，但它似乎并没有为我们解决问题。（我假设此修补程序包含在最新的 .NET 服务包中，因为它看起来不像您可以直接安装它）。我手动添加了该注册表项，但我们仍然看到像上面这样的循环存储过程调用（比每 500 毫秒更频繁地请求同一个会话）

我无法在开发机器上重新创建它。当对同一个会话 ID 发出两个请求时，它似乎会正确阻塞，甚至会尝试命中 SQL，直到第一页释放会话。

有任何想法吗？先感谢您！！！

4

3 回答 3

4

这可能是我需要回答不同问题的情况之一。问题应该是“我为什么要使用 SQL 来存储会话状态信息？” SQL 速度要慢得多，并且与 Web 服务器的连接要多得多，这两者都可能导致了这个问题。我查看了我们的 ASPStateTempSessions 表的大小，发现它只有大约 1MB。我们搬回<sessionState mode="InProc" ... />并解决了问题（并且网站运行得更快）

下一步，当流量需要时，将添加另一个服务器并使用“StateServer”模式，这样我们就可以分散内存使用量。

我想我最初采取这一举措是为了处理不再是问题的内存瓶颈。（这不是处理内存瓶颈的好方法，仅供参考！）

重要编辑：好的，事实证明整个“TempGetStateItemExclusive”不是问题，它只是另一个问题的症状。我们有一些导致阻塞问题的查询，所以每个 SQL 请求都会被踢出。实际的修复是识别和修复阻塞问题。（不过，我仍然相信“InProc”是要走的路）这个链接有助于确定我们的问题：

http://www.simple-talk.com/sql/sql-tools/how-to-identify-blocking-problems-with-sql-profiler/

于 2010-02-05T19:59:39.533 回答
0

已经有一段时间了，但它没有运行以删除陈旧会话的清理工作？是否启用。

这个旧的 KB提到了它。就像我说的，已经有一段时间了。

于 2010-01-28T18:31:22.243 回答
0

只是出于好奇。你打开那​​个过程看看它做了什么吗？

如果它只是在做一个选择语句，你可能会看看它是否使用了 NOLOCK。如果没有，添加 NOLOCK 看看会发生什么。

于 2010-01-28T19:25:45.913 回答