代码之家  ›  专栏  ›  技术社区  ›  JerSchneid

SQL Server请求超时,因为TempGetStateTemExclusive正在连续调用

  •  4
  • JerSchneid  · 技术社区  · 15 年前

    我运行一个流量相当可观的网站(每天约100000次页面浏览量),偶尔该网站会因为SQL Server超时错误而瘫痪。

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

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

    我找到了一个 promising looking hot fix 这似乎解决了这个确切的情况,但似乎并没有解决我们的问题(我假设此修补程序包含在最新的.NET service pack中,因为它看起来不再可以直接安装)。我手动添加了注册表项,但我们仍然可以看到如上所述的循环存储过程调用(请求同一会话的频率比每500毫秒高很多)

    我还没能在开发机器上重新创建这个。当对同一个会话ID发出两个请求时,它似乎会正确地阻塞,甚至尝试点击SQL,直到第一个页面释放会话。

    有什么想法吗?提前谢谢你!!!

    3 回复  |  直到 15 年前
        1
  •  4
  •   JerSchneid    15 年前

    这可能是我需要回答另一个问题的情况之一。问题应该是“为什么我要使用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/

        2
  •  0
  •   gbn    15 年前
        3
  •  0
  •   ChrisLively    15 年前

    如果它只是在生成一个select语句,那么您可以查看它是否在使用NOLOCK。如果没有,则将NOLOCK添加到它并查看发生了什么。