Назад | Перейти на главную страницу

Как определить причину 100% использования ЦП в Службе приложений Azure?

У меня есть пять приложений в плане службы приложений Azure, все разные копии одного и того же приложения для разных клиентов. Это приложение ASP.NET MVC с базой данных SQL.

Сегодня утром я обнаружил медленные и не отвечающие на запросы сайты, что иногда приводило к ошибке 503. После проверки показателей ЦП / памяти для плана службы приложений я обнаружил, что ЦП привязан к 100%:

График загрузки процессора отдельных сайтов показывает, что все они запускаются одновременно, хотя некоторые из них хуже, чем другие:

Я попытался решить проблему, выполнив расширенный перезапуск приложения, но блейд не загружался - я предполагаю, потому что он пытался получить информацию с сервера, который не мог ответить.

В конце концов, я попытался остановить каждый из сайтов один за другим, что привело к обнулению ЦП, а затем снова запустить их, что, казалось, решило проблему, но теперь некоторые из них начинают восстанавливаться.

У меня возникла аналогичная проблема пару недель назад, и я предположил, что разрастаюсь для моего плана приложений, поэтому перешел с S1 на S2, и до сегодняшнего дня все было хорошо.

Я совершенно не понимаю, как понять, в чем причина такого голодного поведения процессора. Может ли кто-нибудь указать мне в правильном направлении, как я могу начать это диагностировать?

У нас была эта проблема несколько раз, и каждый раз оказывалось, что это запускает GC (сборку мусора). Трудно доказать и диагностировать, но в конечном итоге я использую сайт kudo (scm), нажимая инструменты => поддержка (который ведет вас на сайт поддержки приложений.

Отсюда вы выбираете свой каталог (если у вас их несколько) и сайт, нажимаете Analyze => Metrics, затем кнопку Diagnose (НОТА это уже изменилось, поэтому эти шаги могут измениться в любое время), затем снова на Анализ => Дианотика, вы в конечном итоге получите Дамп памяти => Отчет «Состояние анализа». Это должен быть файл mht (который вы можете открыть в ненавистном браузере IE или Edge), а затем найдите ключ «gc».

вы найдете несколько интересных кадров стека вызовов со ссылками на такие вещи, как «GCFrame» или, что более интересно, вызовы «System.Threading.WaitHandle.WaitMultiple», если вы получите слишком много из них, у вашей системы могут быть проблемы со сборкой мусора .

Как решить эту проблему ... эта тема затронута во многих других обсуждениях, потому что это все равно что спрашивать: «Как мне жить в мире с IE 6, который все еще используется?» ...

Лучше всего установить New Relic или Application Insights для этого конкретного приложения. Его можно легко установить через Службу приложений -> Инструменты -> Мониторинг производительности. Это даст вам подробное представление о том, что происходит как на стороне сервера, так и на стороне клиента.

Статья: Мониторинг производительности веб-приложения Azure