常见的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是有用的,但没有进行应有的讨论!
安东·科尔曼

Answers:


7

这确实是一个很好的问题,可惜的是它没有得到更多的爱!

我的瓶颈分析基本理论是将系统视为具有4种有限资源的盒子:处理器,内存,磁盘网络。因此,我想获取每个数字的基本数字来确定包装盒的运行状况。我希望数字易于解释:高是坏,低是好。最好是0,尽管永远无法完美实现(毕竟,我们买了电脑才能正常工作,是吗?)。一旦确定了四种资源中的哪一个是主要瓶颈,就可以继续确定哪个程序或进程正在消耗所有资源,并对是否需要增加该资源做出明智的决定-或调整要使用的程序/过程更少的资源。

我将把本文中使用的主要性能计数器格式化为WMIC查询,因为不需要编写脚本(尽管当然可以!)。您可以直接在cmd控制台中输入以下每个查询:

wmic path Win32_PerfFormattedData_PerfOS_System get ProcessorQueueLength

以上是处理器队列长度。这告诉队列中有多少线程正在等待CPU处理。高数字不好,低数字好。通常,我认为值小于10是一个健康的系统。

wmic path Win32_PerfFormattedData_PerfOS_Memory get PagesInputPerSec

上面是“ 内存”,“每秒页面输入数”,从磁盘读取页面以解决硬页面错误的速率。当进程引用虚拟内存中不在物理内存中的页面并且必须从磁盘中检索页面时,就会发生硬页面错误。不过,此计数器在Perfmon的图形视图中效果最好。在运行正常(没有瓶颈)的计算机上,您会看到偶尔的峰值,因为您将数据从磁盘读入RAM时看到的峰值越多,峰值越多,内存对系统的约束就越大。如果系统经常在一个非零值上停留超过五秒钟的时间,则可能是内存瓶颈。

wmic path Win32_PerfFormattedData_PerfDisk_PhysicalDisk get AvgDiskQueueLength, name

以上是PhysicalDisk,平均磁盘队列长度。我认为这是系统运行状况的关键指标,因为由于过多的页面文件交换,内存瓶颈也会使磁盘陷入瘫痪-而且通常还会提高CPU利用率。它将显示每个已安装磁盘以及所有磁盘总数的项目。性能良好的单个磁盘的此值将为2或更低。对于阵列,将主轴数除以队列长度(例如:阵列中的4个主轴除以队列长度8 = 2,这表示阵列运行良好)。

wmic path Win32_PerfFormattedData_Tcpip_NetworkInterface get OutputQueueLength, PacketsReceivedErrors, Name, currentbandwidth

最后,以上是我们的NIC性能。特别是网络接口,输出队列长度数据包接收错误。这两个计数器使我们知道等待发送多少个数据包,以及有多少入站数据包导致错误,并可能导致重传。我们希望两个数字都保持为零。在此查询中,我还获得了NIC的当前带宽,这是有用的信息。

一旦确定了哪个资源被过度使用,通常我将依靠Process Explorer或Perfmon的process对象来发现哪个进程是资源消耗。


感谢您的详细撰写。我已转换为社区Wiki。我认为这个问题的另一个方面是轮询间隔。有些瓶颈只会短暂出现,而另一些瓶颈的采样频率可能会更低。
Yancy)

好吧,大多数情况下,人们是在被动地(因为已经发现了一些问题)寻找瓶颈,而不是主动地(只是在出现瓶颈的情况下寻找瓶颈)。但是,无论哪种情况,即使是几分钟的性能图也比时间点快照有用得多。
quux
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.