Устранение неполадок с высокой загрузкой ЦП на виртуальных машинах Windows Azure

Сводка

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

В этой статье рассматриваются проблемы с высокой загрузкой ЦП, возникающие на Виртуальные машины (виртуальных машинах) Azure под управлением операционной системы Windows.

Проблемы с высокой загрузкой ЦП на виртуальных машинах Windows Azure

Помимо проблем с задержкой ввода-вывода и сети, для устранения неполадок ЦП и памяти требуются те же средства и действия, что и локальные серверы. Одним из средств, обычно поддерживаемых корпорацией Майкрософт, является PerfInsights (доступно как для Windows, так и для Linux). PerfInsights может предоставить рекомендации по диагностике виртуальных машин Azure в удобном отчете. PerfInsights также является средством-оболочкой, которое может помочь собирать данные Perfmon, Xperf и Netmon в зависимости от флагов, выбранных в средстве.

Большинство существующих средств устранения неполадок с производительностью, таких как Perfmon или Procmon, которые используются для локальных серверов, будут работать на виртуальных машинах Windows Azure. Однако PerfInsights явно предназначен для виртуальных машин Azure для предоставления дополнительных аналитических сведений, включая рекомендации по Azure, рекомендации по SQL, графики задержки ввода-вывода с высоким разрешением, вкладки ЦП и память и т. д.

Независимо от того, выполняется ли он в режиме User-Mode или в режиме ядра, любой поток активного процесса требует циклов ЦП для выполнения кода, на основе чего он создан. Многие проблемы напрямую связаны с рабочей нагрузкой. Тип рабочей нагрузки, которая существует на сервере, управляет потреблением ресурсов, включая ЦП.

Общие факторы

В ситуации с высокой загрузкой ЦП часто используются следующие факторы:

• Последнее изменение кода или развертывание, которое в основном применимо к таким приложениям, как службы IIS, Microsoft SharePoint, Microsoft SQL Server или сторонние приложения.

• Недавнее обновление, которое может быть связано с обновлением на уровне ОС или накопительными обновлениями и исправлениями на уровне приложения.

• Изменение запроса или устаревшие индексы. SQL Server и приложения уровня данных Oracle также имеют оптимизацию плана запросов в качестве еще одного фактора. Изменения данных или отсутствие соответствующих индексов могут привести к тому, что несколько запросов становятся более ресурсоемкими.

• Для виртуальной машины Azure. Существуют определенные процессы, такие как RDAgent, и процессы, относящиеся к расширению, такие как агент мониторинга, агент MMA или клиент безопасности, которые могут привести к высокому потреблению ЦП. Эти процессы должны рассматриваться с точки зрения конфигурации или известных проблем.

Устранение проблемы

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

Например, если процесс SQL Server (sqlservr.exe), следующими шагами будет анализ того, какой запрос использовал наибольшее число циклов ЦП за определенный период времени.

Определение области проблемы

Вот несколько вопросов, которые следует задать при устранении проблемы.

• Существует ли шаблон проблемы? Например, возникает ли проблема с высокой загрузкой ЦП в определенное время каждый день, неделю или месяц? Если да, можно ли сопоставить эту проблему с заданием, отчетом или именем входа пользователя?

• Возникла ли проблема с высокой загрузкой ЦП после недавнего изменения кода? Вы применили обновление в Windows или в приложении?

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

• Возникла ли проблема с высокой загрузкой ЦП в Azure в одном из следующих условий?

  • После недавнего повторного развертывания или перезапуска
  • При изменении номера SKU или типа виртуальной машины
  • При добавлении нового расширения
  • После внесения изменений в подсистему балансировки нагрузки

Предостережения Azure

Общие сведения о рабочей нагрузке. При выборе виртуальной машины вы можете занить количество виртуальных ЦП (vCPU) при просмотре общей ежемесячной стоимости размещения. Если рабочая нагрузка является ресурсоемкой, выбор номера SKU виртуальной машины меньшего размера с одним или двумя виртуальными ЦП может вызвать проблемы с рабочей нагрузкой. Протестируйте различные конфигурации для рабочей нагрузки, чтобы определить оптимальные вычислительные возможности, которые требуются.

Существуют определенные серии виртуальных машин, такие как серия B (режим ускорения), которые рекомендуется использовать для контроля качества (QA) и тестирования. Использование этих рядов в рабочей среде ограничивает вычислительные возможности после исчерпания кредитов ЦП.

Для известных приложений, таких как SQL Server, Oracle, RDS (службы удаленных рабочих столов), Виртуальный рабочий стол Azure, IIS или SharePoint, существуют статьи с рекомендациями по Azure, в которых приведены рекомендации по минимальной настройке этих рабочих нагрузок.

Текущие проблемы с высокой загрузкой ЦП

Если проблема возникает прямо сейчас, это лучшая возможность записать трассировку процесса, чтобы определить причину проблемы. Для поиска процесса можно использовать существующие средства, которые вы использовали для локальных серверов Windows. Служба поддержки Azure рекомендует следующие средства для виртуальных машин Azure.

PerfInsights

PerfInsights — это рекомендуемое средство из поддержка Azure для устранения проблем с производительностью виртуальных машин. Он предназначен для охвата рекомендаций и выделенных вкладок анализа для ЦП, памяти и графов ввода-вывода с высоким разрешением. Его можно запустить OnDemand через портал Azure или из виртуальной машины. Вы можете поделиться данными с командой поддержка Azure.

Запуск PerfInsights

PerfInsights доступен как для ОС Windows , так и для Linux . Ниже приведены параметры для Windows.

Запуск и анализ отчетов с помощью портал Azure

При установке через портал Azure фактически устанавливает расширение на виртуальной машине. Пользователи также могут установить PerfInsights в качестве расширения, перейдя непосредственно в колонку Расширения в колонке виртуальной машины, а затем выбрав параметр производительности диагностика.

вариант 1 портал Azure

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

вариант 2 портал Azure

Перейдите к разделу Диагностика и решение проблем в колонке виртуальной машины и найдите проблемы с производительностью виртуальной машины.

Если выбрать устранение неполадок, загрузит экран установки PerfInsights.

Если нажать кнопку Установить, то при установке будут доступны другие параметры сбора.

Нумерованные параметры на снимке экрана связаны со следующими комментариями:

1. Для параметра Высокий ЦП выберите Анализ производительности или Дополнительно.

2. При добавлении здесь симптомов они будут добавлены в отчет, что поможет вам поделиться информацией со службой поддержки Azure.

3. Выберите длительность сбора данных. Для параметра Высокий ЦП выберите не менее 15 минут или более. В режиме портал Azure можно собирать данные до 15 минут. В течение более длительных периодов сбора необходимо запустить программу в качестве исполняемого файла на виртуальной машине.

4. Если служба поддержки Azure попросит вас собрать эти данные, вы можете добавить номер билета здесь. Это поле не является обязательным.

5. Выберите это поле, чтобы принять лицензионное соглашение(EULA).

6. Выберите это поле, если вы планируете сделать этот отчет доступным для группы поддержки Azure, помогающей в этом случае.

Отчет хранится в одной из учетных записей хранения в вашей подписке. Его можно просмотреть и скачать позже.

Запуск PerfInsights из виртуальной машины

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

• Расширенный сценарий

  • PerfInsights /run advanced xp /d 300 /AcceptDisclaimerAndShareDiagnostics

• Сценарий медленной (производительности) виртуальной машины

  • PerfInsights /run vmslow /d 300 /AcceptDisclaimerAndShareDiagnostics /sa <StorageAccountName> /sk <StorageAccountKey>

Выходные данные команды будут находиться в той же папке, в которой вы сохранили исполняемый файл PerfInsights.

Что искать в отчете

После запуска отчета расположение содержимого зависит от того, выполнялось ли оно через портал Azure или в качестве исполняемого файла. Для любого из этих вариантов получите доступ к созданной папке журнала или скачайте (если портал Azure) локально для анализа.

Запустите портал Azure

Запуск из виртуальной машины

Структура папок должна выглядеть следующим образом:

1. Все дополнительные коллекции, такие как Perfmon, Xperf, Netmon, журналы SMB, журналы событий и т. д., можно найти в папке Output.

2. Фактический отчет вместе с анализом и рекомендациями.

3. Для производительности (VMslow) и Advanced отчет собирает сведения о производительности за время выполнения PerfInsights.

4. В журналах событий отображается быстрое представление полезных сведений о сбоях на уровне системы или процесса.

С чего начать

Откройте отчет PerfInsights. На вкладке Результаты все выбросы регистрируются с точки зрения потребления ресурсов. Если имеются случаи высокой загрузки ЦП, на вкладке Результаты он будет классифицироваться как высокий или средний.

Как и в предыдущем примере, PerfInsights был запущен в течение 30 минут. В течение половины этого времени выделенный процесс истощал ЦП на более высокой стороне. Если бы один и тот же процесс выполнялся на протяжении всего времени сбора, уровень влияния изменился бы на HIGH.

Если развернуть событие Результаты , вы увидите несколько ключевых сведений. На вкладке перечислены процессы в порядке убывания по среднему потреблению ЦП и показано, связан ли этот процесс с системой, приложением Майкрософт (SQL, IIS) или сторонним процессом.

Дополнительные сведения

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

На вкладке Основные потребители ЦП есть два отдельных раздела, и здесь можно просмотреть статистику по каждому процессору. Конструкция приложения часто либо Single-Threaded, либо закрепляется на одном процессоре. В этом сценарии одно или несколько ядер выполняются на 100 %, а другие — на ожидаемых уровнях. Эти сценарии являются более сложными, так как средняя загрузка ЦП на сервере выполняется должным образом, но процессы, закрепленные на ядрах с высоким уровнем использования, будут выполняться медленнее, чем ожидалось.

Второй раздел (не менее важный) — Top Long Running Cpu Consumers(Top Long Running Cpu Consumers). В этом разделе показаны сведения о процессе и шаблон использования ЦП. Список сортируется по высокому среднему значению потребителей ЦП в верхней части.

Этих двух вкладок будет достаточно, чтобы задать путь для следующих действий по устранению неполадок. В зависимости от процесса, который приводит к высокой загрузке ЦП, вам придется ответить на вопросы, которые были заданы ранее. Для таких процессов, как SQL Server (sqlservr.exe) или IIS (w3wp.exe), требуется определенная детализация изменений запроса или кода, которые вызывают это условие. Для системных процессов, таких как WMI или Lsass.exe, необходимо следовать другому пути.

Для процессов, связанных с виртуальными машинами Azure, таких как RDAgent, OMS и исполняемые файлы расширений мониторинга, может потребоваться исправить новую сборку или версию, получив помощь в службе поддержки Azure.

Perfmon

Perfmon — это одно из самых ранних средств для устранения проблем с ресурсами в Windows Server. Он не дает четкого отчета с рекомендациями или выводами. Вместо этого требуется, чтобы пользователь изучил собранные данные и использовал определенный фильтр по разным категориям счетчиков.

PerfInsights собирает Perfmon в качестве дополнительного журнала для VMSlow и расширенных сценариев. Тем не менее, Perfmon можно собирать независимо и имеет следующие дополнительные преимущества:

• Его можно собирать удаленно.

• Его можно запланировать с помощью задач.

• Его можно собирать в течение более длительного времени или в непрерывном режиме с помощью функции опрокидывания.

Рассмотрим тот же пример, который показан в PerfInsights, чтобы увидеть, как Perfmon отображает эти данные. Ниже перечислены необходимые категории счетчиков.

• Сведения о > процессоре %Время процессора > _Total

• Обработка > %ProcessorTime > всех экземпляров

С чего начать

Имена выходных файлов Perfmon имеют .blg расширение. Эти файлы можно собирать независимо или с помощью PerfInsights. В этом обсуждении вы будете использовать Perfmon .blg , включенный в данные PerfInsights и собранный в предыдущем примере.

В Perfmon отсутствуют отчеты, готовые к работе с пользователем. Существуют различные представления, которые изменяют тип графа, но фильтрация процесса (или работа, необходимая для выявления виновного процесса) выполняется вручную.

Примечание.

Средство PAL может использовать .blg файлы и создавать подробные отчеты.

Чтобы начать, выберите категорию Добавить счетчики .

1. В разделе Доступные счетчики выберите счетчик %ProcessorTime в категории Сведения о процессоре .

2. Выберите _Total, чтобы получить статистику по всем объединенным ядрам.

3. Нажмите Добавить. В окне отображается %ProcessorTime в разделе Добавленные счетчики.

После загрузки счетчиков вы увидите графики тренда в временном интервале коллекции. Счетчики можно выбрать или очистить. До сих пор вы добавили только один счетчик.

Каждый счетчик будет иметь значения Average, Minimum и Maximum . Сосредоточьтесь на значениях Average и Maximum , так как среднее значение может отличаться в зависимости от длительности сбора данных. Если высокая активность ЦП наблюдалась в течение 10 минут, а общая коллекция составляла 40 минут, средние значения будут гораздо ниже.

На предыдущем графике тенденций показано, что общее число процессоров составляло около 80 процентов в течение примерно 15 минут.

Определение процесса

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

Для этой задачи необходимо очистить или удалить ранее добавленные счетчики %ProcessorTime , а затем добавить новую категорию:

• Обработка > %ProcessorTime > всех экземпляров

Эта категория будет загружать счетчики для всех процессов, выполняющихся в это время.

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

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

Так как для общей суммы всегда будет отображаться линейчатая полоса, сосредоточьтесь на полосах с высокой скоростью исчерпания. Чтобы очистить представление, можно удалить другие отрезки. Теперь вернитесь в режим строки .

Теперь легче поймать виновного процесса. По умолчанию значения Max и Min кратны количеству ядер на сервере или потоков процесса.

Список доступных средств не заканчивается на PerfInsights for Perfmon. У вас есть доступ к другим средствам, таким как ProcessMonitor (ProcMon) или Xperf. Существует множество сторонних средств, доступных для использования по мере необходимости.

Средства мониторинга Azure

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

Базовые счетчики (по умолчанию)

Включение Azure Monitor

После включения метрик Azure Monitor программное обеспечение устанавливает расширение на виртуальной машине, а затем начинает собирать детализированные метрики, включая счетчики Perfmon.

Базовые категории счетчиков задаются по умолчанию. Однако можно также задать настраиваемую коллекцию.

После включения параметров эти счетчики гостевых можно просмотреть в разделе Метрики . Вы также можете задать оповещения (включая сообщения электронной почты), если метрики достигают определенного порогового значения.

Дополнительные сведения об использовании Azure Monitor для управления виртуальными машинами Azure см. в статье Мониторинг виртуальных машин Azure с помощью Azure Monitor.

Реактивное устранение неполадок

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

Если эта проблема была однократной, может быть трудно определить, какое приложение вызвало ее. Если виртуальная машина Azure настроена для использования OMS или других диагностика отслеживания, вы по-прежнему можете получить аналитические сведения о причинах проблемы.

Если вы работаете с повторяющимся шаблоном, соберите данные в течение того времени, когда проблема, вероятно, возникнет в следующем.

PerfInsights пока не имеет возможности запланированного выполнения . Тем не менее, Perfmon можно запустить и запланировать с помощью командной строки.

Команда Logman

Команда Logman Create Counter используется для запуска коллекции Perfmon через командную строку, планирования ее с помощью диспетчера задач или для удаленного запуска.

Пример (включает режим удаленного сбора)

Logman create counter LOGNAME -u DOMAIN\USERNAME * -f bincirc -v mmddhhmm -max 300 -c "\\SERVERNAME\LogicalDisk(*)\*" "\\SERVERNAME\Memory\*" "\\SERVERNAME\Network Interface(*)\*" "\\SERVERNAME\Paging File(*)\*" "\\SERVERNAME\PhysicalDisk(*)\*" "\\SERVERNAME\Process(*)\*" "\\SERVERNAME\Redirector\*" "\\SERVERNAME\Server\*" "\\SERVERNAME\System\*" "\\SERVERNAME\Terminal Services\*" "\\SERVERNAME\Processor(*)\*" "\\SERVERNAME\Cache\*" -si 00:01:00

Logman.exe также можно запустить с однорангового компьютера виртуальной машины Azure в той же виртуальной сети.

Дополнительные сведения об этих параметрах см. в статье Создание счетчика logman.

После сбора данных Perfmon во время возникновения проблемы оставшиеся действия для анализа данных будут такими же, как обсуждалось ранее.

Заключение

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

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

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

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.