Загальні запити моніторингу WQL


12

Які WQL запити ви використовуєте для моніторингу типових вузьких місць для Windows? Що б ви використовували для отримання даних, подібних до "top" або "netstat"? На якому інтервалі Ви б опитувались?

Ось декілька, які мені здаються корисними.

SELECT PercentDiskTime, AvgDiskQueueLength, DiskReadBytesPerSec, DiskWriteBytesPerSec FROM Win32_PerfFormattedData_PerfDisk_PhysicalDisk

SELECT Caption, CommittedBytes, AvailableBytes, PercentCommittedBytesInUse, PagesPerSec, PageFaultsPerSec FROM Win32_PerfFormattedData_PerfOS_Memory

SELECT PercentProcessorTime FROM Win32_PerfFormattedData_PerfOS_Processor

SELECT Caption, WorkingSet, PageFaultsPerSec,IOReadBytesPerSec, IOWriteBytesPerSec, ThreadCount, HandleCount FROM Win32_PerfFormattedData_PerfProc_Process

SELECT Caption, BytesReceivedPerSec, BytesSentPerSec FROM Win32_PerfFormattedData_Tcpip_NetworkInterface

Відмінний матеріал, це корисно і програмістам прикладних програм. Більшість цих матеріалів недоступні безпосередньо через виклик Win32 API; Корисний, але не обговорений WMI стільки, скільки повинен бути!
Андон М. Коулман

Відповіді:


7

Це справді велике питання , і прикро, що воно не набуло більше любові!

Моя основна теорія аналізу вузьких місць полягає в тому, щоб розглянути систему як коробку з чотирма видами кінцевих ресурсів: процесор, пам'ять, диск та мережа . Тому я хочу отримати базові цифри для кожного з них, щоб визначити стан коробки. Я хочу цифри, які легко інтерпретувати: високий - поганий, низький - хороший. 0 найкраще, хоча ніколи не досягається абсолютно (адже ми купили комп'ютер для роботи , так?). Як тільки я бачу, який із чотирьох ресурсів є основним вузьким місцем, я можу приступити до визначення того, яка програма чи процес споживає всі ресурси, і прийму освічене рішення щодо того, чи потрібно мені збільшувати цей ресурс - або налаштувати програму / процес на використання менше ресурсу.

Я відформатую основні лічильники ефективності, які я використовую з цієї статті , як WMIC-запити, оскільки сценарії не потрібні (хоча це, безумовно, можливо!). Ви можете ввести кожен із цих запитів безпосередньо в консоль cmd:

wmic path Win32_PerfFormattedData_PerfOS_System get ProcessorQueueLength

Вгорі - довжина черги процесора . Це говорить про те, скільки потоків чекає в черзі, щоб обробляти процесор. Високі цифри погані, низькі цифри - хороші. Як правило, я вважаю, що значення <10 є здоровою системою.

wmic path Win32_PerfFormattedData_PerfOS_Memory get PagesInputPerSec

Вище - це пам'ять, введення сторінок в секунду , швидкість, з якою читаються сторінки з диска, щоб усунути неполадки жорсткої сторінки. Несправності на жорсткій сторінці виникають, коли процес посилається на сторінку у віртуальній пам'яті, яка не знаходиться у фізичній пам'яті, і повинна бути отримана з диска. Цей лічильник найкраще працює на графіку Перфмона. На здоровому комп’ютері (не з вузьких місць) ви будете бачити випадкові шипи, коли дані зчитуються з диска в оперативну пам'ять, чим більше шипів ви бачите, і чим вище вони йдуть, тим більше об'єм пам'яті обмежує система. Якщо система часто залишається на ненульовому значенні протягом періодів довших, скажімо, п’яти секунд, ви, мабуть, маєте пам’яті з вузькою пам’яттю.

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. Зокрема, мережевий інтерфейс, довжина черги виводу та отримані помилки . Ці два лічильники дають нам знати, скільки пакетів очікує на надсилання та скільки вхідних пакетів викликали помилки, які, ймовірно, призвели до повторної передачі. Ми хочемо, щоб обидва числа залишилися на нулі. У цьому запиті я також отримую поточну пропускну здатність NIC, що є корисною інформацією.

Після того, як я визначив, який ресурс надмірно використовувався, я зазвичай залежав або від провідника процесів, або від об'єкта процесу Perfmon, щоб виявити, який процес - це свиня.


Дякуємо за детальне оформлення. Я перетворився на вікі спільноти. Я думаю, що ще одним аспектом цього питання є інтервали опитування. Деякі вузькі місця з’являться лише коротко, інші можуть бути відібрані з меншою частотою.
Янсі

Що ж, найчастіше хтось шукає вузькі місця реактивно (тому що певна проблема спостерігається), а не активно (просто перебуваючи на огляді у випадку вузького місця). У будь-якому випадку, хоча, парфумні графіки за кілька хвилин набагато корисніші, ніж знімки в момент часу.
quux
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.