主页 / server / 问题 / 54753
In Process
Yancy
Asked: 2009-08-17 10:06:08 +0800 CST

常见的 WQL 监控查询

  • 772

您将使用哪些 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
monitoring

1 个回答

  1. 这是一个真正伟大的问题，可惜它没有得到更多的爱！

    我的瓶颈分析的基本理论是将系统视为具有 4 种有限资源的盒子：处理器、内存、磁盘和网络。所以我想获得每个这些的基本数字来确定盒子的健康状况。我想要易于解释的数字：高是坏的，低是好的。0 是最好的，尽管永远无法完美实现（毕竟我们买电脑是为了工作，嗯？）。一旦我看到四种资源中的哪一种是主要瓶颈，我就可以继续确定哪个程序或进程正在消耗所有资源，并就是否需要增加该资源做出明智的决定 - 或调整程序/进程以使用资源少。

    我将把本文中我使用的主要性能计数器格式化为 WMIC 查询，因为不需要编写脚本（尽管这当然是可能的！）。您可以将这些查询中的每一个直接输入到 cmd 控制台中：

    wmic path Win32_PerfFormattedData_PerfOS_System get ProcessorQueueLength

    以上是处理器队列长度。这告诉有多少线程在队列中等待由 CPU 处理。高数不好，低数好。一般来说，我认为值 <10 是一个健康的系统。

    wmic path Win32_PerfFormattedData_PerfOS_Memory get PagesInputPerSec

    以上是Memory, Pages Input per Second，从磁盘读取页面以解决硬页面错误的速率。当进程引用虚拟内存中不在物理内存中的页面时，就会发生硬页面错误，并且必须从磁盘中检索。不过，这个计数器在 Perfmon 的图表视图中效果最好。在一台健康（非瓶颈）的计算机上，当数据从磁盘读取到 RAM 时，您会看到偶尔出现的尖峰，您看到的尖峰越多，而且它们越高，系统受到的内存限制就越多。如果系统经常保持在一个非零值的时间超过 5 秒，那么您可能遇到了内存瓶颈系统。

    wmic path Win32_PerfFormattedData_PerfDisk_PhysicalDisk get AvgDiskQueueLength, name

    以上是PhysicalDisk，Average Disk Queue Length。我认为这是系统健康状况的关键指标，因为内存瓶颈也会由于过多的页面文件交换而使磁盘陷入困境 - 并且通常也会推高 CPU 利用率。它将显示每个已安装磁盘的项目以及所有磁盘的总数。性能良好的单个磁盘将具有此值 2 或更低。对于阵列，将主轴数除以队列长度（例如：阵列中的 4 个主轴除以队列长度 8 = 2，这意味着阵列性能良好）。

    wmic path Win32_PerfFormattedData_Tcpip_NetworkInterface get OutputQueueLength, PacketsReceivedErrors, Name, currentbandwidth

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

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

    • 7

相关问题