Возникли некоторые проблемы с производительностью образа виртуальной машины (у меня нет доступа к хосту виртуальной машины, только гостевая ОС).
Пытаюсь определить, почему существуют периоды времени от 10 до 60 секунд, когда сервер просто перестает отправлять какие-либо запросы.
При этом у меня работает несколько счетчиков производительности, но я заметил нечто очень странное: вскоре после начала этих «мертвых» периодов все счетчики моих приложений ASP.NET (активные сеансы, количество экземпляров конвейера, выполняемые запросы) падают до нуля, а затем резко возвращаются к нормальному уровню, как только мы выходим из «мертвого» периода. Смотрите график здесь:
Я знаю на 100%, что эти сеансы, даже если они и исчезли из статистики счетчика, все еще продолжались в течение всего периода времени.
Кто-нибудь раньше видел такое поведение счетчиков? Возможно ли, что какая-то нехватка ресурсов виртуальной машины вызывает неправильное поведение этих счетчиков и, возможно, мертвые периоды в целом?
решение1
У нас только что была эта проблема - сводила меня с ума и вызывала множество других проблем. В этот низкий момент запросы останавливались BeginRequestили MapRequestHandler- затем они все внезапно начинали проходить через состояния снова через 10+ секунд.
Основная причина в конечном итоге заключалась в том, что приложение IIS записывало файл в свой собственный каталог /bin. IIS обнаружил это и выполнил мягкую перезагрузку, временно сократив количество прослушивающих рабочих процессов до 0 (показано Pipeline Instance Countи причина, по которой я нашел этот вопрос). Однако это не отображалось как новые процессы или что-то подобное в каком-либо другом инструменте.
Мы нашли это, сделав минидамп всех процессов IIS с помощьюDebugDiag2от MS во время одного из замедлений, обнаруженных путем пингования небольшой конечной точки с помощью fiddler. У DebugDiag есть отчет CrashHangAnalysis. В этом отчете было много информации - потребовалось некоторое время, чтобы найти HttpRuntime Shutdown Reportс трассировкой стека, включая System.Web.DirectoryMonitor.FireNotificationsи System.Web.Compilation.BuildManager.OnWebHashFileChange.
Это заставило меня заглянуть в каталог prod bin и обнаружить, что там записывался ошибочный журнал электронной почты, из-за чего IIS перезапускал приложение. Это было особенно странно, потому что график памяти приложения в New Relic просто показывал то, что выглядело как постоянная утечка памяти, но на самом деле все приложение перезапускалось (вроде как) и просто увеличивало существующую память. Это не было похоже на обычный перезапуск, и PID остались прежними. Понятия не имею, какую магию пытался сделать IIS.
Кроме того, изменение дополнительных настроек IIS AppPool Disable Recycling for Configuration Changesна Trueне решило эту проблему, как предлагалось вэтот другой вопрос. Чтобы исправить это, нам пришлось изменить и повторно развернуть двоичные файлы.