我有一个ASP经典应用程序，目前在IIS6中运行，但通常是由于原来的程序员没有遵循“最佳实践”，这个应用程序几个小时后会引发内存不足错误。
最初，我曾经在StackOverflow上提过这个问题 ，引用了原来的问题。
理想的解决scheme是将应用程序迁移到.NET，或排除原始代码以查找内存泄漏并对其进行补救。 然而，有近一百万行代码…它需要时间来发现各种问题并修复它们，需要更多的时间来发现更多的内存泄漏。
我的问题是：IIS7会比IIS6更好或更有效地处理VBScript内存使用，这将是一个改进？ 将应用程序迁移到IIS7以帮助缓解这个问题值得吗？ 显然整个问题不会消失，因为仍然有泄漏，但会改善吗？
该应用程序在Windows Server 2003上运行。
如果你转移到64位，它会运行更长的时间。 它可以使用尽可能多的内存，你可以扔在它之前炸毁。 在x86中，在爆炸之前，您可能甚至不会达到2 GB的进程限制。 然后，您可以更less的时间回收应用程序池，并希望在数小时后减less用户的影响。
但它是“更好还是更有效地处理VBScript”？ 不。
迁移可能比它的价值更麻烦。 IIS 6基本上具有与7相同的回收选项，这可能是我首先考虑的情况。
如果实际内存泄漏，则可以实施基于内存限制的回收。
例如：如果应用程序最终popup800MB的私人字节，它将被回收。 （回收创build一个新的过程来取代旧的，然后终止旧的）。
如果您的应用程序对回收没有很好的回应（回收会导致状态丢失 – 例如会话状态，内存中的variables等），那么这可能是一个不错的select。 如果它是无状态的，你也可以看看设置maxprocesses> 1（一个“networking园”），这在理论上将失败前的时间乘以工作进程的数量。 （这个假设你有n * 2GB的内存来扔它）
如果这样做，并且您的应用程序具有已定义的生命周期，那么执行比此更短的回收时间间隔（例如，每1小时回收一次）。