Счетчики производительности ASP.NET временно обнуляются
Возникли проблемы с производительностью образа виртуальной машины (у меня нет доступа к хосту виртуальной машины, только к гостевой ОС).
Попытка определить, почему бывают периоды времени от 10 до 60 секунд, когда сервер просто перестает отправлять какие-либо запросы.
При этом у меня работает несколько счетчиков производительности, но я заметил кое-что очень странное, вскоре после начала этих "мертвых" периодов все мои счетчики приложений ASP.NET (Sessions Active, Pipeline Instance Count, Requests Executing) падают до нуля, а затем стреляют. вернемся к нормальному уровню, как только мы выйдем из «мертвого» периода. Смотрите график здесь:
Я знаю со 100% уверенностью, что эти сеансы, даже если они выпали из статистики счетчика, продолжали работать в течение всего периода времени.
Кто-нибудь видел раньше такое поведение со счетчиков? Возможно ли, что какая-то нехватка ресурсов виртуальной машины приводит к неправильной работе этих счетчиков и, возможно, к мертвым периодам в целом?
У нас просто была эта проблема - сводила меня с ума и вызывала множество других проблем. Во время этой низкой точки запросы останавливались в BeginRequest или MapRequestHandler - тогда они все внезапно начинали бы снова проходить через состояния через 10+ секунд.
Основная причина в том, что приложение IIS записывало файл в свой собственный каталог / bin. IIS обнаружил это и произвел мягкую перезагрузку, временно уменьшив количество слушающих рабочих процессов до 0 (показано Pipeline Instance Count и причина, по которой я нашел этот вопрос). Однако это не проявилось как новые процессы или что-то подобное ни в каком другом инструменте.
Мы нашли это, взяв минидамп всех процессов IIS, используя DebugDiag2 от MS во время одного из замедлений, обнаруженных путем проверки связи с небольшой конечной точкой с помощью скрипта. 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 не предотвратил эту проблему, как предложено в этот другой вопрос. Нам пришлось изменить и повторно развернуть двоичные файлы, чтобы исправить это.