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