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

Отслеживание высокой загрузки ЦП Windows Server

У меня есть сервер Windows 2003 (64-разрядный), работающий как виртуальная машина на удаленном хостинге. (Я просто арендую этот конкретный виртуальный экземпляр, поэтому я не знаю, на каком базовом оборудовании он работает, кроме того, что он представляется виртуальной машине как имеющий 8 доступных ЦП.)

Проблема в том, что примерно 1-2 недели назад taskmgr.exe начал показывать что-то вроде общей загрузки ЦП 60%, равномерно распределенной по 7 из 8 процессов, но с одним скачком на 100%. И сервер отвечает, как и следовало ожидать, когда он так занят: это собака. Я, очевидно, хотел бы выяснить, что вызывает это.

Проблема в том, что процентные значения ЦП для каждого процесса, как показано в taskmgr.exe или procxp.exe, не составляют в сумме около 100%. Другими словами, процесс простоя системы составляет где-то около 40%, а некоторые другие процессы могут добавить еще 10%, но откуда берутся остальные 50%? Другими словами, что-то занимает 50% моего процессора, и его нигде нет в диспетчере задач. (Установлен флажок «Показывать процессы от всех пользователей».)

Я пытался остановить все службы, которые мог, но ни одна из них не повлияла на процессор. Перезапуск сервера не имеет никакого значения: к тому времени, когда я снова вхожу в систему, процессор снова привязан. Procexp.exe не показывает ничего необычного.

Я могу придумать два возможных объяснения: (1) какой-то руткит проник на мой сервер и скрывается из списка процессов; или (2) taskmgr.exe внезапно (и впервые) показывает использование остальной части окна, а не только этого конкретного экземпляра (хотя это кажется неправильным).

Есть ли другие предложения по отслеживанию этого?

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

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

Во-вторых, вы упомянули о 8-процессорной виртуальной машине. Вы абсолютно уверены, что вам нужно столько ядер? Ты уверен? Хорошо, спросите себя, действительно ли они вам нужны. Причина в том, что при виртуализации несколько ядер работают не так, как если бы вы работали на голом железе. Единственный раз, когда ваша виртуальная машина получит процессорное время на хосте, - это когда доступно 8 ядер. Если 8 ядер недоступны, вы не получите циклов ЦП. Само собой разумеется, что на даже умеренно загруженном хосте гипервизору гораздо сложнее планировать время процессора для 8-ядерной ВМ, чем для одноядерной ВМ. По этой причине я рекомендую придерживаться одного ядра, если это на 100% не является абсолютно необходимым для приложения, после чего я могу выделить 2 или, самое большее, 4 ядра, и в этом случае я буду чертовски уверен, что больше нечего происходит на хосте, поэтому производительность этой виртуальной машины не страдает.

Итак - может у вас есть руткит? Конечно, возможно, и так, и вам лучше проявить должную осмотрительность, чтобы определить, так ли это. Если нет, то вам, безусловно, есть на что посмотреть.