일반적인 WQL 모니터링 쿼리


12

일반적인 Windows 병목 현상을 모니터링하기 위해 어떤 WQL 쿼리를 사용 하시겠습니까? '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는 유용하지만 설명해야 할만큼 논의되지 않았습니다!
Andon M. Coleman

답변:


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으로 데이터를 읽을 때 스파이크가 많을수록 가끔씩 급증하는 경향이 있으며, 높을수록 시스템의 메모리가 제한됩니다. 시스템이 종종 5 초보다 긴 기간 동안 0이 아닌 값을 유지하는 경우 메모리 병목 현상이 발생했을 수 있습니다.

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 성능이 있습니다. 특히 네트워크 인터페이스, 출력 대기열 길이패킷 수신 오류 . 이 두 카운터는 전송 대기중인 패킷 수와 인바운드 패킷 수를 통해 오류를 일으켜 재전송을 발생시킨 원인을 알려줍니다. 두 숫자를 모두 0으로 유지하려고합니다. 이 쿼리에서는 유용한 정보 인 NIC의 현재 대역폭도 얻습니다.

어떤 리소스가 과도하게 사용되는지 확인한 후에는 일반적으로 프로세스 탐색기 또는 Perfmon의 프로세스 개체에 의존하여 어떤 프로세스가 리소스 호그인지 확인합니다.


자세한 글을 보내 주셔서 감사합니다. 커뮤니티 위키로 전환했습니다. 이 질문의 또 다른 측면은 폴링 간격이라고 생각합니다. 일부 병목 현상은 잠깐 동안 만 나타나고 다른 병목 현상은 더 적은 빈도로 샘플링 될 수 있습니다.
Yancy

글쎄, 대부분의 경우 병목 현상을 사전 예방 적으로 보지 않고 (일부 문제가 관찰 되었기 때문에) 병목 현상을 반응 으로 찾고 있습니다. 두 경우 모두 몇 분 동안의 perfmon 그래프는 특정 시점 스냅 샷보다 훨씬 유용합니다.
quux
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.