У меня есть этот веб-сайт, написанный на C #. около 400-500 пользователей онлайн в любое время. он был на 32-битной машине с Windows 2008 и никогда не блокировался / не замедлялся из-за увеличения потребления памяти, пока я не обновил его сервер, чтобы выиграть 2008 R2 64 бит.
Старый сервер имел только 4 гигабайта оперативной памяти и четырехъядерный процессор на 2 ГГц. сайт работал нормально. так как я обновил сервер, я заметил (2 раза за 10 дней) он начал есть барана. вчера вечером он поднялся до 4 гб баран. при увеличении барана реакция тормозит довольно сильно. утилизация пула приложений не помогает. Мне нужно перезапустить рабочий процесс для восстановления.
Я заметил, что это обычно происходит при постоянных ошибках. Поскольку я ничего не менял в коде, могу ли я предположить, что это не связано с утечкой памяти в коде?
кто нибудь сталкивался с чем-то подобным?
То же самое происходит, если я создаю постоянные ошибки с классическим asp.
Спасибо
Во-первых, в качестве общего предложения, если вашему приложению определенно не требуется 64-битная адресация, запустите его в 32-битном пуле приложений. Это, естественно, ограничивает использование памяти до 4 ГБ на процесс.
Почему это может быть важно? Ну, потому что 4 ГБ для 64-битного приложения - это ошибка округления! Если платформа .Net не чувствует нехватки памяти, она может не беспокоиться о выполнении сборки мусора. Это не лучший ответ, и я не знаю, почему это может быть так в R2, а не R1, за исключением возможного ответа на размер памяти.
При повторном использовании: повторное использование должно создавать новый рабочий процесс при следующем запросе и по умолчанию дает старому до 90 секунд для завершения - повторное использование делает перезапустите рабочий процесс (или, по крайней мере, сообщает WAS запустить новый WP в следующий раз, когда поступает запрос, и вежливо сообщает последнему WP, что он перерабатывается). Если повторное использование перекрытия не отключено, вы должны увидеть новый w3wp с новым PID, как только будет получен следующий запрос для этого сайта.
Если вы все еще видите утечку в 32-разрядном пуле приложений, вам необходимо устранить ее как утечку памяти - подумайте о том, чтобы сделать дамп памяти процесса, когда он находится в состоянии высокой памяти, а затем посмотрите на его отладку с помощью sos.dll или psscor2.dll, чтобы найти основного потребителя памяти.
Возможно, я нашел причину. Я не знаю, почему этого не произошло на iis7 или 6, но вот что происходит.
Это происходит, если вы устанавливаете страницы ошибок iis / asp.net на динамическую страницу, такую как 500.aspx, 404.aspx, а ошибка распространяется на весь сайт, поэтому каждый запрос получает одинаковую ошибку. Похоже, что из-за блокировки сеанса iis ожидает завершения до обработки страницы динамической ошибки и ставит ваш запрос в очередь. по мере увеличения количества запросов память увеличивается.