我们已经开始在我们的 Intranet 服务器上看到实例，对于任何页面，服务器只响应错误页面“HTTP/1.1 New Session Failed”。看来我们可以通过运行 IISRESET 来修复它，但这感觉就像我们只是在治疗症状。
该服务器是在 Windows Server 2003 上运行 IIS6 的虚拟化服务器，具有 0.5Gb 的 RAM。我们的 Intranet 是用 ASP 编写的，但我们也有在网站上运行的 ASP.NET 2.0 应用程序。该站点设置为匿名和集成身份验证。
是什么导致 IIS 进入此错误状态？服务器是否会因请求而饱和，即我们需要向外扩展并将一些应用程序移动到另一台服务器上？
我见过KB210842但我不确定它是否适用，因为它适用于 IIS 4
您的事件日志可能包含更多信息。检查应用程序日志和系统日志是否有错误。
对于具有任何可观负载的 Windows 2003 + IIS 6，512MB 的 RAM 是不够的——尤其是对于 ASP .NET 2.0。升级到 1GB 会有很大的不同。
我想在这里添加一些信息。问题只有一个直接原因——没有足够的内存新会话分配。真正的问题是什么消耗了内存，显然每个不同情况下的答案都是不同的。先说几句我的设置：
我托管在基于 Virtuozzo 的 VPS-es 上，您可以更清楚地看到问题所在。有什么区别 - 在 VMWare 上你有一些类似于真实机器的东西 - 带有交换文件和内存，它们可能与真实的东西不完全对应，但实际上 VMWare（和任何基于硬件虚拟化的解决方案）可以被视为真实机器. 使用 Virtuozzo，您只能获得 RAM - 其中一部分位于页面文件中，但从 VPS 内部您看不到其中的区别。所以，我使用的 VPS-es 内存只有 286MB，这就是我可以使用的所有内存，当您使用内存设置为 286 的 VMWare 时，您可能还有一些额外的交换空间，因此您的可用 RAM 会更多（如何当然，很大程度上取决于页面文件的大小）。
在 286 MB 的机器上，我可以托管大约 15-20 个应用程序和相当数量的访问者。我正在使用自己的框架和组件——包括自己的数据库引擎。我确信不会发生内存泄漏（经过多年的测试），但总共 286MB 的内存非常薄。您会不时收到“新会话失败” - 问题是如何避免在重新启动（IIS 或机器）之前被卡住。答案是调整 COM+ 应用程序的内存限制，并且可能是其他一些回收选项。
要检查的另一件事是 ASP 缓存选项 - 在内存中缓存了多少文件，缓存了多少脚本引擎（这也发生在内存中）。默认值非常大，效果类似于内存泄漏 - 特别是如果您有许多 ASP 文件和许多站点（缓存是在全局级别配置的，但在工作进程中完成）。
因此，通过微调 COM+ 应用程序和缓存选项，您可以让您的服务器运行，如果不是绝对顺利，那么至少确保它会自动恢复，每天最多只有几个请求（比如说十万个）返回 New会话失败。如果您将 COM+ 应用程序的数量保持在较低水平（最多 2-3 个），您可以保持跟踪并选择适当的内存限制，也许为对会话丢失不敏感的应用程序设置时间间隔回收等。
还有一件事要考虑在同一台服务器上的 .NET 应用程序。没有注意，他们可以杀死其他所有东西并获取所有服务器资源。问题是垃圾收集 - ASP.NET（和任何 .NET）应用程序不会释放它们的内存，因为一些 ASP 经典或 PHP 应用程序需要它并且即使它们不使用它也会保持内存占用 - 最终它们将释放它，但他们可能会保留几个小时 - 就是这样。解决方案是 - 避免在同一台服务器上混合 .NET 和非 .NET 应用程序，如果您无法避免将 .NET 应用程序放在单独的 COM+ 池中并设置严格的内存限制并使它们尽可能低。
好吧，我希望这会有所帮助。我有很多管理可用内存不足的服务器的经验 - 这不是很困难，但需要注意，而不是希望问题会随着补丁或其他神奇的解决方案而消失。
出现该错误时有多少可用内存？如果您已用尽所有内存，则新会话将失败。
似乎 IIS6 没有足够的内存来分配给会话。如果这种情况经常发生，您可能需要在应用程序池上设置内存回收限制。这样它就不会“吃掉”你所有的可用资源。请记住，回收内存将导致会话丢失。
您是在 IIS 中还是在进程外提供程序中运行会话状态。将会话状态移动到提供程序将允许您使用来自会话状态服务而不是 IIS 进程的内存。此外，会话状态将在 IIS 和应用程序域重新启动后继续存在。我还注意到 512Meg 偏小。