У меня есть приложение ASP Classic, которое в настоящее время работает в IIS6, но часто из-за того, что исходный программист не следовал «передовым методам», это приложение через несколько часов выдает ошибку Out of Memory.
Изначально я спросил этот вопрос на StackOverflow применительно к исходной проблеме.
Идеальным решением будет миграция приложения на .NET или устранение неполадок в необработанном коде, чтобы найти утечку памяти и устранить ее. Однако существует почти миллион строк кода ... и потребовалось время, чтобы найти различные проблемы и исправить их, и больше времени требуется, чтобы найти дальнейшие утечки памяти.
Мой вопрос: будет ли IIS7 обрабатывать использование памяти VBScript лучше или эффективнее, чем IIS6, что было бы улучшением? Стоит ли переносить приложение на IIS7, чтобы решить эту проблему? Очевидно, что проблема не исчезнет полностью, поскольку утечки все еще существуют, но улучшится ли ситуация?
Приложение работает на Windows Server 2003.
Он работал бы дольше, если бы вы перешли на x64. Он мог бы использовать столько памяти, сколько вы могли бы использовать, прежде чем взорваться. В x86 вы, вероятно, даже не достигнете предела процесса в 2 ГБ, прежде чем взорваться. Тогда вы сможете реже перерабатывать пул приложений и, надеюсь, по прошествии нескольких часов, когда это затронет меньшее количество пользователей.
Но «обрабатывает ли он VBScript лучше или эффективнее»? Нет.
Миграция может быть больше проблем, чем она того стоит. IIS 6 имеет в основном те же варианты утилизации, что и 7, и, вероятно, это то, что я бы рассмотрел в первую очередь в вашей ситуации.
Если это действительно утечка памяти, вы можете реализовать переработку на основе ограничения памяти.
Например: если приложение в конечном итоге извлекает 800 МБ частных байтов, оно будет переработано. (При повторном использовании создается новый процесс, который заменяет старый, а затем старый завершается).
Если ваше приложение плохо реагирует на повторное использование (повторное использование вызывает потерю состояния - например, состояния сеанса, переменных в памяти и т. Д.), Это может быть хорошим вариантом. Если он не имеет состояния, вы также можете посмотреть на установку maxprocesses> 1 («веб-сад»), что теоретически умножит время до отказа на количество рабочих процессов. (это предполагает, что у вас есть n * 2 ГБ ОЗУ, чтобы бросить на него)
Если это так, и у вашего приложения есть определенный срок жизни, реализация более короткого интервала перезапуска, чем это могло бы работать (например, перезапуск каждые 1 час).