Возможные причины высокой загрузки ЦП процесса taskmgr.exe на ВМ?

У меня были похожие симптомы не на ВМ, а на ноутбуке с Win7. Taskmgr.exe и другие процессы (например, Winmerge.exe) занимали 13% процессорного времени (один из 8). Эта проблема была временно устранена путем перезагрузки, поэтому я много этим занимался.

После долгого исследования я понял, что виновником является WRSA.exe, Webroot Secure Anywere (программное обеспечение для защиты от вирусов и других видов защиты). Как только я завершил этот процесс, все снова стало быстрым, как магия! Пока не уверен, что использовать вместо Webroot для защиты.

Ну, что если вы просто выйдете из диспетчера задач?:-)

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

Производительность на сервере виртуализации должна оцениваться сначала на физическом сервере, а затем на виртуальных машинах.

Внутри виртуальной машины вычисления времени не точны, особенно если вы перегружаете VCPU.

Кроме того, время, затрачиваемое процессором на системное время, может очень сильно повлиять на производительность. Даже 10% могут удвоить время отклика виртуальной машины, даже если общий процессор используется менее чем на 15%.

Убедитесь, что вы не чрезмерно фиксируете память и хост-сервер не меняет местами. Это смоет ваше выступление. Убедитесь, что инструменты VMware установлены и работают драйверы паравиртуализации (прямой ввод-вывод, baloon).

У меня была похожая проблема со стандартной виртуальной машиной 2003 на vSphere 5.1. Первоначально я настроил очень простую виртуальную машину (4 ГБ vRAM, 20 ГБ vDisk) с 1 сокетом и 2 ядрами. На холостом ходу процессор виртуальной машины постоянно находился в диапазоне 30-50%, хотя не было установлено никаких программ, и он был полностью обновлен и т. Д.

Я пробовал разные конфигурации ЦП, и когда я изменил число vCores с 1 сокета и 2 ядер на 1 сокет и 4 ядра (и перезапустил), все успокоилось - на холостом ходу на 99%.

Я не знаю достаточно о методологии vCPU, чтобы дать объяснение, но, возможно, это поможет кому-то

Сам хост - DL385 Gen8 с 2-мя 16-ядерными процессорами AMD.

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

Если он использует 20% ЦП для заданного набора показателей, то это потому, что не так много ЦП для начала. Если вы выполняете ту же нагрузку на машине с 10-кратным ЦП, это займет всего 2% ЦП.

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

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

Кстати, имейте в виду, что вам не следует беспокоиться о том, что процессор расходуется, если он не потребляет и не делает что-то полезное, или делает недостаточно, потому что у вас есть больше дел.

Расход 100% процессора не плохой, желательно. Это означает, что для данной рабочей нагрузки вы работаете так быстро, как можете. Следите за очередью ЦП, если это> 0, то вам нужно больше ЦП.

Использование < 100% ЦП не годится, особенно когда вы пытаетесь выполнить работу. Имейте в виду, что процессор является временным ресурсом. Неиспользованные циклы не могут быть сохранены и не имеют никакой ценности, они просто представляют упущенные возможности для достижения цели.

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