Это действительно великий вопрос , и это позор, что он не получил больше любви!
Моя основная теория анализа узких мест заключается в том, чтобы рассматривать систему как блок с 4 видами конечных ресурсов: процессор, память, диск и сеть . Поэтому я хочу получить базовые цифры для каждого из них, чтобы определить состояние коробки. Я хочу, чтобы числа легко интерпретировались: высокий - это плохо, низкий - это хорошо. 0 - лучший, но никогда не достижимый результат (ведь мы купили компьютер для работы , а?). Как только я увижу, какой из четырех ресурсов является основным узким местом, я могу определить, какая программа или процесс потребляет все ресурсы, и принять обоснованное решение о том, нужно ли мне увеличивать этот ресурс - или настроить программу / процесс для использования. меньше ресурса.
Я отформатирую основные счетчики производительности, которые я использую в этой статье , как запросы WMIC, потому что сценарии не требуются (хотя это, безусловно, возможно!). Вы можете ввести каждый из этих запросов непосредственно в консоль cmd:
wmic path Win32_PerfFormattedData_PerfOS_System get ProcessorQueueLength
Выше - длина очереди процессора . Это говорит о том, сколько потоков ожидает в очереди для обработки ЦП. Высокие цифры плохо, низкие цифры хорошо. Обычно я считаю значение <10 здоровой системой.
wmic path Win32_PerfFormattedData_PerfOS_Memory get PagesInputPerSec
Выше - память, количество страниц в секунду , скорость чтения страниц с диска для устранения ошибок жесткого диска. Жесткие сбои страниц возникают, когда процесс ссылается на страницу в виртуальной памяти, которой нет в физической памяти, и которую необходимо извлечь с диска. Этот счетчик лучше всего работает в графическом представлении Perfmon. На исправном (не узком месте) компьютере вы можете увидеть случайные всплески, когда данные читаются с диска в ОЗУ, чем больше всплесков вы видите, и чем они выше, тем больше ограничивается память системы. Если система часто использует ненулевое значение в течение периодов, превышающих, скажем, пять секунд, возможно, у вас узкая область памяти.
wmic path Win32_PerfFormattedData_PerfDisk_PhysicalDisk get AvgDiskQueueLength, name
Выше PhysicalDisk, средняя длина очереди диска . Я считаю, что это является ключевым индикатором работоспособности системы, поскольку узкие места в памяти также будут перегружать диск из-за чрезмерной перестановки файлов подкачки - и часто также увеличивают загрузку ЦП. Он покажет элемент для каждого подключенного диска, а также общее количество всех дисков. Хорошо работающий одиночный диск будет иметь это значение 2 или ниже. Для массивов разделите число шпинделей на длину очереди (например: 4 шпинделя в массиве делятся на длину очереди 8 = 2, что означает, что массив работает хорошо).
wmic path Win32_PerfFormattedData_Tcpip_NetworkInterface get OutputQueueLength, PacketsReceivedErrors, Name, currentbandwidth
И наконец, выше у нас есть производительность NIC. В частности, сетевой интерфейс, длина очереди вывода и ошибки, полученные пакетами . Эти два счетчика сообщают нам, сколько пакетов ожидает отправки и сколько входящих пакетов вызвало ошибки, которые, вероятно, привели к повторной передаче. Мы хотим, чтобы оба числа остались на нуле. В этом запросе я также получаю текущую пропускную способность сетевого адаптера, которая является полезной информацией.
После того, как я определил, какой ресурс используется чрезмерно, я обычно полагаюсь на либо Process Explorer, либо объект процесса Perfmon, чтобы определить, какой процесс является источником ресурсов.