我有一个在 Windows Server 2016 上的 IIS 10 上运行的 ASP.NET 应用程序。 它连接到同一场中另一台计算机上的 SQL Server。 当负载增加 1-5k 个会话时，突然所有会话都被丢弃。
应用程序池不回收。过程仍在进行中。
使用了内存、CPU、磁盘、网络接口，但仍然很好，没有压力。 CPU 总是低于 50%，内存总是低于 50% 网络总是低于 30Mb/s（远低于带宽限制）。
我的代码没有错误。已经检查过了。
windows 日志中没有错误。
已检查 IIS 限制和超时。他们看起来很好。
在同一台机器上，我有不同的应用程序池，它们不受影响。
有什么想法吗？
【问题讨论】：
许多事情都可能导致会话状态神秘地消失。
您的 sessionState 超时已过期 您更新您的 web.config 或其他导致 AppDomain 回收的文件类型 IIS 中的 AppPool 回收
如果您使用的是 IIS 7 或 7.5，请注意以下几点：
默认情况下，IIS 将 AppPools 设置为在一段时间不活动后自行关闭。 默认情况下，IIS 将 AppPools 设置为每 1740 分钟回收一次（显然取决于您的根配置，但这是默认设置） 在 IIS 中，检查 AppPool 的“高级设置”。其中有一个名为“空闲超时”的属性。将其设置为零或高于默认值 (20)。 在 IIS 中，检查 AppPool 的“回收”设置。您可以在此处启用或禁用您的 AppPool 进行回收。向导的第 2 页是一种将每种 AppPool 关闭类型记录到事件日志的方法。 如果您使用的是 IIS 6，则应用相同的设置（大多数情况下使用不同的获取方式），但是让它们记录回收更麻烦。以下是让 IIS 6 记录 AppPool 回收事件的方法的链接：
-
如果您要更新 Web 应用程序上的文件，您应该预计所有会话都会丢失。这就是野兽的本性。但是，您可能不会期望它会发生多次。如果您更新了 15 个或更多文件（aspx、dll 等），您可能会在一段时间内多次重新启动，因为访问该站点的用户会重新编译这些页面。查看这两个链接：
http://support.microsoft.com/kb/319947
将 numCompilesBeforeAppRestart 设置为更高的数字（或手动反弹您的 AppPool）将消除此问题。
-
您始终可以处理 Application_SessionStart 和 Application_SessionEnd 以在创建或结束会话时得到通知。 HttpSessionState 类还有一个 IsNewSession 属性，您可以检查任何页面请求以确定是否为活动用户创建了新会话。
-
最后，如果在您的情况下可能的话，我已经成功地使用了 SQL Server 会话模式。如果您在其中存储大量数据（每个请求从 SQL Server 加载并保存全部数据），则不建议这样做，如果您将自定义对象放入其中可能会很痛苦（因为它们必须是可序列化的)，但它在我无法将我的 AppPool 配置为不回收几个小时的共享托管方案中帮助了我。就我而言，我存储了有限的信息，并且对性能没有不利影响。除此之外，现有用户将默认重用其 SessionID，而我的用户从未注意到他们的内存中 Session 被 AppPool 回收丢弃的事实，因为他们的所有状态都存储在 SQL Server 中。
功劳归用户 Adam Sills (Losing Session State)
【讨论】：