Как определить причину 100% использования ЦП в службе приложений Azure?
У меня есть пять приложений в плане службы приложений Azure, все разные копии одного и того же приложения для разных клиентов. Это приложение ASP.NET MVC с базой данных SQL.
Сегодня утром я проснулся и увидел медленные и не отвечающие на запросы сайты, иногда приводит к ошибке 503. После проверки показателей ЦП / памяти для плана службы приложений я обнаружил, что ЦП привязан к 100%:
И график процессорного времени отдельных сайтов показывает, что все они выключаются одновременно, хотя некоторые из них хуже, чем другие:
Я попытался решить проблему, выполнив расширенный перезапуск приложения, но блейд не загружался - я предполагаю, потому что он пытался получить информацию с сервера, который не мог ответить.
В конце концов я попытался остановка каждого из сайтов один за другим, что привело к обнулению ЦП, а затем повторный запуск их снова, что, казалось, решило проблему, но теперь некоторые из них начинают подниматься обратно.
Я испытал аналогичная проблема пару недель назад, и предполагалось, что я становлюсь слишком большим для моего плана приложений, поэтому обновился с S1 до S2, и это ' Я был в порядке до сегодняшнего дня.
Я совершенно не понимаю, как выяснить, в чем причина такого «голодного» поведения процессора. Может ли кто-нибудь указать мне в правильном направлении, как я могу начать это диагностировать?
Лучше всего установить New Relic или Application Insights для этого конкретного приложения. Его можно легко установить через Службу приложений -> Инструменты -> Мониторинг производительности. Это даст вам подробное представление о том, что происходит как на стороне сервера, так и на стороне клиента.
У нас несколько раз возникала эта проблема, и каждый раз оказывалось, что она убегает от сборки мусора. Это сложно доказать и диагностировать, но в конечном итоге я использую сайт kudo (scm),щелкнув инструменты => поддержка (что приведет вас к сайту поддержки приложений.
Отсюда вы выбираете свой каталог (если у вас их несколько) и сайт, нажимаете Анализировать => Показатели, затем кнопку Диагностика ( ПРИМЕЧАНИЕ , это уже изменилось, поэтому эти шаги можно изменить в любое время), затем снова на Analyze => Dianotics, вы в конечном итоге получите отчет Memory Dump => «Состояние анализа». Это должен быть файл mht (который вы можете откройте в ненавистном браузере IE или Edge), затем найдите ключ «gc».
вы найдете несколько интересных кадров стека вызовов со ссылками на такие вещи, как «GCFrame» или, что более интересно, вызовы «System.Threading.WaitHandle» .WaitMultiple "если у вас их слишком много, у вашей системы могут быть проблемы со сборкой мусора.
Как решить эту проблему ... эта тема рассматривается во многих других потоках, потому что это все равно, что спрашивать, как мне жить в мире, где IE 6 все еще используется? "...
Посмотрите эти видеоролики, чтобы узнать больше об устранении проблем с высокой загрузкой ЦП в службе приложений Azure: