我们将会话设置为 120 分钟后超时。然而，最近，其中一台生产服务器遇到了大量问题。由于我无法访问服务器盒本身，因此我在这里处理的信息有限。我们有两台服务器来部署我们的网站。服务器 A 一直运行良好，但服务器 B 经常遇到这些过期会话问题。这是最近的事，就像过去两周一样。
我知道我没有提供足够的信息来直接查明问题，但有哪些问题可能导致会话无缘无故地被重置？
【问题讨论】：
工作解决方案：
<system.web> <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" cookieless="false" timeout="60" /> <machineKey validationKey="DCB7132A24938F2166E362214ADAD861FA6B819E0A337F0E63257F87014A37B5EBC5D9F9AD107C38E3D3378BC35CBAF81407F3E4D8BA430FD65348DDCC469623" decryptionKey="DD09731F76271B2AAE6AE957626F8D1B8E3CBF11EF8E3CDDF01332CDF914D4B5" validation="SHA1" decryption="AES" /> </system.web>
**注意：或生成您自己的机器密钥：http://aspnetresources.com/tools/machineKey
现在您可以回收您的应用程序池、修改您的 web.config 或重新启动您的 Web 服务 - 会话就位！ 现在，您还可以在池中启用网络花园以获得更高的性能。
【讨论】：
显然，我修复了它。我并排打开了两台服务器的 IIS7 应用程序池高级设置并注意到一个区别：服务器 A 上的 Regular Time Interval 设置为 5，服务器 B 上的设置为 1740。我将服务器 A 的设置更改为 1740（默认值）并且问题停止了马上。
奇怪的是，当服务器管理员回滚到一个月前时，这种情况就开始发生了。不知何故，有些东西被抬高了，这些设置一定已经改变了。
虽然我仍然不完全了解我是如何解决问题的，但这只是一个巧合，或者 5 分钟设置太短是问题所在。
如果有人想说明这一点，那么一定要这样做。
【讨论】：
我想到了几件事：
正如@Steve Morgan 所说，如果您使用的是进程内会话和“粘性”会话，那么它可能是由负载均衡器中的问题引起的。在负载平衡时，会话应该始终处于进程外，因为坦率地说，“粘性”并不意味着会话不会在两台机器之间反弹。这只是意味着它不太可能。如果负载均衡器过载，则用户将被发送到与第一个不同的服务器。
应用程序池回收是导致会话丢失的另一个原因；再次由于使用进程内会话管理。如果您移至进程外，它将隐藏问题。这里真正的问题需要调查，因为它几乎总是错误代码的结果。
我的猜测是您遇到了多种问题。从转移到进程外会话开始并设置状态服务器。这将克服直接的痛苦。然后开始查看平衡器和 Web 服务器日志，看看您是否需要更好的平衡器或需要更改代码以堵塞内存泄漏。
【讨论】：
最近在您的服务器上放置了任何新网站吗？ 我们在转移到 .net 4 时遇到了这个问题，并且没有考虑为新的 .net 4 站点（与 .net 2/3.5 站点相反）创建新的应用程序池。 这导致应用程序池不断重启，因为它们无法在同一个应用程序池下运行。
您是否还上传了任何可能使其自身陷入循环的新代码，这也可能导致应用程序池崩溃，从而导致会话重新启动？
另一个想法..您是否有任何更新等待在此服务器上安装..这也产生了无法解释的问题。
【讨论】：
应用程序池可能由于多种原因之一被回收。有许多设置，超过其中任何一个都会导致 ASP.NET 循环使用：
如果您使用进程内会话状态，如果应用程序池回收，会话将丢失。
如果没有更改任何设置，则很可能您遇到了内存问题，可能是由于内存泄漏（这可能不是“真正的”泄漏，而是在应该释放它们时保留的引用）。
您说您正在使用两台服务器。如果会话状态丢失，听起来您正在使用进程内会话状态。在这种情况下，我假设您正在使用带有“粘性会话”的负载平衡（后续请求转到同一服务器）？
如果我错了，您使用的是共享状态（例如 SQL Server 会话状态提供程序或状态服务器），是不是您的服务器上的时钟不同步？
【讨论】：