Consultas comuns de monitoramento de WQL

12

Quais consultas WQL você usaria para monitorar afunilamentos típicos do Windows? Qual você usaria para obter dados semelhantes ao 'top' ou 'netstat'? Em que intervalo você pesquisaria?

Aqui estão alguns que considero úteis.

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
    
por Yancy 18.08.2009 / 20:29

1 resposta

7

Esta é realmente uma ótima ótima pergunta , e é uma pena que não tenha conseguido mais amor!

Minha teoria básica de análise de gargalos é tratar o sistema como uma caixa com 4 tipos de recursos finitos: processador, memória, disco, e rede . Então, quero obter números básicos para cada um deles para determinar a integridade da caixa. Eu quero números que sejam fáceis de interpretar: alto é ruim, baixo é bom. 0 é melhor, embora nunca perfeitamente realizável (afinal compramos o computador para fazer o trabalho , eh?). Depois de ver qual dos quatro recursos é o principal gargalo, posso determinar qual programa ou processo está consumindo todos os recursos e tomar uma decisão instruída sobre se preciso aumentar esse recurso - ou ajustar o programa / processo para usar menos do recurso.

Vou formatar os principais contadores de desempenho que eu uso, de este artigo , como WMIC consulta, porque nenhum script é necessário (embora seja certamente possível!). Você pode inserir cada uma dessas consultas diretamente no console do cmd:

wmic path Win32_PerfFormattedData_PerfOS_System get ProcessorQueueLength

Acima está Comprimento da Fila do Processador . Isso informa quantos threads estão aguardando na fila para serem manipulados pela CPU. Números altos são ruins, números baixos são bons. Geralmente, considero um valor <10 como um sistema saudável.

wmic path Win32_PerfFormattedData_PerfOS_Memory get PagesInputPerSec

Acima está Memória, Entrada de Páginas por Segundo , a taxa em que as páginas são lidas do disco para resolver falhas de página rígida. As falhas de página rígida ocorrem quando um processo se refere a uma página na memória virtual que não está na memória física e deve ser recuperada do disco. Este contador funciona melhor na visualização gráfica do Perfmon. Em um computador saudável (não afunilado), você verá picos ocasionais à medida que os dados são lidos do disco para a RAM, quanto mais pontos você vê, e quanto mais alto eles ficam, mais memória é restrita ao sistema. Se o sistema ficar frequentemente com um valor diferente de zero por períodos maiores do que, digamos, cinco segundos, você provavelmente terá um sistema de gargalo de memória.

wmic path Win32_PerfFormattedData_PerfDisk_PhysicalDisk get AvgDiskQueueLength, name

Acima está PhysicalDisk, Average Average Queue Length . Considero que este é o principal indicador de integridade do sistema, já que os gargalos de memória também sobrecarregarão o disco devido à troca excessiva de arquivos de paginação - e, muitas vezes, também aumentará a utilização da CPU. Ele mostrará um item para cada disco montado, bem como um total de todos os discos. Um disco único de bom desempenho terá esse valor em 2 ou menos. Para matrizes, divida o número de eixos pelo comprimento da fila (por exemplo: 4 eixos na matriz divididos por um comprimento de fila de 8 = 2, o que significa que a matriz está tendo um bom desempenho).

wmic path Win32_PerfFormattedData_Tcpip_NetworkInterface get OutputQueueLength, PacketsReceivedErrors, Name, currentbandwidth

E finalmente, acima, temos o desempenho da NIC. Especificamente Interface de Rede, Comprimento da Fila de Saída e Pacotes de Erros Recebidos . Esses dois contadores nos informaram quantos pacotes estão aguardando para serem enviados e quantos pacotes de entrada causaram erros que provavelmente resultaram em retransmissões. Queremos que os dois números permaneçam em zero. Nesta consulta, também recebo a largura de banda atual da NIC, que é uma informação útil.

Depois de determinar qual recurso é usado em excesso, geralmente dependo do Process Explorer ou o objeto de processo do Perfmon para descobrir qual processo é o porco do recurso.

    
por 18.08.2009 / 12:23