我有一个当前在 IIS6 中运行的 ASP Classic 应用程序，但通常由于原始程序员没有遵循“最佳实践”，该应用程序会在几个小时后抛出内存不足错误。
最初，我问的是StackOverflow 上的这个问题参考原始问题。
理想的解决方案是将应用程序迁移到 .NET，或者对原始代码进行故障排除以查找内存泄漏并进行补救。但是，代码有近一百万行……查找各种问题并修复它们需要时间，而查找进一步的内存泄漏则需要更多时间。
我的问题是：IIS7 处理 VBScript 内存使用情况是否会比 IIS6 更好或更高效，从而带来改进？将应用程序迁移到 IIS7 是否值得帮助缓解此问题？显然，整个问题不会消失，因为仍然存在泄漏，但它会有所改善吗？
该应用程序在Windows Server 2003上运行。
答案1
如果迁移到 x64，它会运行更长时间。在崩溃之前，它可以使用尽可能多的内存。在 x86 中，在崩溃之前，您可能甚至不会达到 2 GB 的进程限制。然后，您可以减少回收应用程序池的频率，并希望在受影响的用户较少的几个小时后回收。
但是它是否“能够更好或更有效地处理 VBScript”？没有。
答案2
迁移可能得不偿失。IIS 6 的回收选项与 7 基本相同，这可能是我在您的情况中首先考虑的。
如果它确实泄漏了内存，您可以实现基于内存限制的回收。
例如：如果应用程序最终弹出 800MB 的私有字节，它将被回收。（回收将创建一个新进程来替换旧进程，然后终止旧进程）。
如果您的应用程序对回收的响应不是太差（回收会导致状态丢失 - 例如会话状态、内存变量等），这可能是一个不错的选择。如果它是无状态的，您还可以考虑设置 maxprocesses > 1（“网络花园”），理论上这会将故障前的时间乘以工作进程的数量。（这假设您有 n * 2GB RAM 可以投入其中）
如果确实如此，并且您的应用具有定义的生命周期，则实现比该周期更短的回收间隔（例如，每 1 小时回收一次）。