Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 4)

Опубликовано: 19 Апреля, 2023

  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 2)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 3)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 5)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 6)

Введение

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

Пользовательские рабочие нагрузки

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

Если вы посмотрите на рисунок А, то увидите, что диспетчер задач открыт на вкладке «Процессы». На этой вкладке перечислены различные процессы, запущенные на сервере. Как вы можете видеть на рисунке, вкладка «Процессы» разбивает процессы на категории, такие как «Приложения» и «Фоновые процессы». Однако отсутствует одна вещь — информация о процессах, связанных с пользователем.

Изображение 15419
Рисунок A. На вкладке «Процессы» не отображается информация о пользователе.

Конечно, это не означает, что вы не можете использовать диспетчер задач для получения информации о пользователе. Вы можете. На предыдущем рисунке вы могли заметить, что диспетчер задач содержит вкладку «Пользователи». На этой вкладке, показанной на рисунке B, перечислены все пользователи, которые в данный момент вошли на сервер. Как вы можете видеть на рисунке, диспетчер задач фактически разбивает общую рабочую нагрузку на каждого пользователя. Например, на рисунке видно, что Администратор отвечает за 0,5% от общего использования ЦП и потребляет 81,3 МБ памяти.

Изображение 15420
Рисунок B: На вкладке «Пользователи» рабочая нагрузка сервера разбита по каждому пользователю.

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

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

Если вы посмотрите на рисунок C, вы увидите, что список для каждого отдельного пользователя можно расширить. Когда вы расширяете пользователя, Диспетчер задач показывает, какие процессы выполняет пользователь и какой уровень ресурсов потребляет каждый процесс. Это позволяет вам точно определить, что делает пользователь, чтобы затормозить вашу виртуальную машину.

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

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

Если вы посмотрите на рисунок D, вы увидите диспетчер задач в том виде, в каком он существовал в Windows Server 2008 R2. Первое, что вы можете заметить в этой версии диспетчера задач, это то, что список процессов очень короткий. Причина этого в том, что процессы, связанные с пользователем, по умолчанию не отображаются. Если вы хотите просмотреть процессы, связанные с пользователем, вы должны установить флажок в нижней части окна.

Изображение 15422
Рисунок D. Диспетчер задач Windows Server 2008 R2 по умолчанию не отображает пользовательские процессы.

Когда вы устанавливаете флажок «Показать процессы от всех пользователей», список процессов значительно увеличивается, как показано на рисунке E. Однако, к сожалению, список организован немного более бессистемно, чем в диспетчере задач Windows Server 2012..

Изображение 15423
Рисунок E: Список процессов увеличивается, когда вы устанавливаете флажок «Показать процессы от всех пользователей».

Глядя на предыдущие рисунки, вы могли заметить, что даже диспетчер задач Windows Server 2008 R2 содержит вкладку «Пользователи». Однако, к сожалению, вкладка «Пользователи» не разбивает информацию о рабочей нагрузке системы на каждого пользователя, как это делается в Windows Server 2012. Вместо этого на вкладке «Пользователи» просто перечислены все сеансы пользователей и вы можете либо отключить пользователя, либо выйти из него.. Вы можете увидеть, как выглядит вкладка «Пользователи» на рисунке F.

Изображение 15424
Рисунок F. Это вкладка «Пользователи» диспетчера задач Windows Server 2008 R2.

Получение более подробной информации о производительности

В предыдущей статье этой серии я подвожу итоги, показывая вам вкладку «Производительность» диспетчера задач. Как вы можете видеть на рисунке G, эта вкладка предоставляет вам графическое представление совокупного использования ЦП, памяти и сети для сервера.

Изображение 15425
Рисунок G. На вкладке «Производительность» диспетчера задач отображается совокупная информация об использовании ЦП, памяти и сетевых ресурсов.

Глядя на рисунок выше, вы могли заметить ссылку в нижней части окна с надписью Open Resource Monitor. Щелкнув по этой ссылке, Windows откроет инструмент под названием «Монитор ресурсов».

Я склонен думать о Resource Monitor как об инструменте для устранения неполадок производительности среднего уровня. Монитор ресурсов немного более продвинут, чем диспетчер задач (хотя он во многом похож на этот диспетчер задач). Однако в то же время Монитор ресурсов менее продвинут, чем Монитор производительности.

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

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

Вывод

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

  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 2)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 3)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 5)
  • Устранение неполадок с низкой производительностью ВМ в Hyper-V (часть 6)