Windows에 내장된 성능모니터를 사용하면, 원하는 기간에 대한 서버 또는 PC의 시스템 자원 활용도를 분석할 수 있습니다.
기본적으로 [시작]-[실행]을 클릭하고, ‘PerfMon’을 실행하여, 아래의 화면을 표시할 수 있습니다.
본 문서와 블로그에서는 성능모니터 도구 사용법 자체보다는, 시스템의 자원의 각 요소를 모니터링 하는 방법을 다루고자 합니다.
성능모니터 도구 사용법이 익숙하지 않다면, 아래의 자료를 참고할 수 있습니다.
성능 모니터링 시작 가이드http://technet.microsoft.com/ko-kr/library/dd744567%28v=ws.10%29.aspx시스템의 자원은 CPU, 메모리, 디스크, 네트워크 등, 크게 4가지 요소로 이루어져 있습니다.
그 중 CPU에 대해서는 보통 CPU 활용도, 커널 관련 입출력 등의 성능 카운터를 종합적으로 분석하게 됩니다.
카운터 소개 – [성능 카운터 정보 : 성능오브젝트\카운터(인스턴스명) ]
Processor\%Processor Time (_Total)
프로세서 사용 시간의 백분율이며, 전체 CPU시간에서 유휴 CPU시간을 제외한 시간의 백분율입니다.
CPU 사용률이 높으면, 어떤 사용자 프로세스가 CPU시간을 많이 쓰는지, 또는 시스템에서 소비하는 것인지 구분해 판단하게 됩니다.
Processor\%Privileged Time (_Total)
전체 CPU시간에서, 유휴 CPU시간과 사용자 CPU시간(User mode)을 제외한, 즉 시스템(커널)의 CPU 활용률 입니다.
사용자 프로세스나 일반 응용프로그램 이외에도 시스템의 CPU 사용률이 높아서 성능에 문제가 생기는 경우도 있습니다.
예를 들면, 네트워크 관련 드라이버, 그래픽 드라이버 등의 문제, 또는 사용자 프로그램의 지나친 커널 구성요소 호출에 의해서도
이 성능카운터의 값이 매우 높게 나타날 수 있습니다.
Process\%Processor Time (프로세스명)
특정 프로세스의 CPU 사용률입니다. IIS의 경우 웹응용프로그램 프로세스인 w3wp.exe를 모니터 하게 됩니다.
System\Context Switches/sec
프로세서가 실행할 대상 쓰레드를 변경한 수입니다. 다른 쓰레드의 실행은 비단 멀티쓰레드 응용프로그램 실행에 한정되는 것이 아니라,
시스템의 여러 프로세스를 실행하면서, 또는 단일 쓰레드 프로그램이라도 커널API를 호출하여 수행하면서 변경이 일어나게 됩니다.
Context Switch가 매우 많으면, CPU사용률과는 별개로 CPU 처리 지연의 원인이 될 수 있습니다.
System\System Calls/sec
시스템 전체에서의 운영 체제 서비스 루틴의 호출 수입니다. Context Switch와 마찬가지로 지나치게 많은 호출이 발생하면,
CPU성능에 영향을 주게 됩니다.
System\Processor Queue Length
실행 준비가 되어 있는 쓰레드 중에서, 프로세서 큐(대기열)에 있는 쓰레드 수입니다. 일반적으로 프로세서가 바쁘지 않다면,
대기열의 길이는 ‘0’이 됩니다. 따라서, CPU 상태가 현재 여유가 있는지, 아니면 매우 바빠서 추가로 명령을 실행할 여유가 없는 건인지 판단하는
매우 중요한 카운터입니다.
성능 카운터의 모니터링 위에서 언급된 카운터를 모두 추가하여, 차트로 모니터링을 하거나, 일정 기간 데이터를 파일로 기록해 두었다가 나중에 분석할 수 있습니다.
성능 모니터 도구의 세부 기능을 활용하면, 성능 기록뿐 아니라, 알림, 로그 분석 등을 통해 유용한 정보를 확인할 수 있습니다.
Windows의 성능, 특히 CPU성능의 분석을 위해 모니터링이 필요한 카운터를 정리해보았습니다.
프로세서 병목의 판단
이번에는 수집된 성능 데이터를 기반으로,
CPU 병목을 정의하는 과정에 대해 정리해 보고자 합니다.
먼저 시스템의 성능과 CPU사용률(%Processor Time)에 대한
기본적인 이해가 필요할 것으로 생각됩니다.
각 성능 요소(카운터)의 정의는 이전 글에서 살펴보았습니다.
프로세서 성능의 분석에서 CPU사용률은, 불과 20%미만이라도 CPU병목으로 판단될 수 있고, 75%이상이어도 CPU병목이 아닐 수 있습니다.
CPU 사용률이 10%이지만, 과도한 Context Switch나 System call이 발생하면,
이것 역시 CPU병목을 유발할 수 있고,
CPU 사용률이 80%인 경우, WWW 서비스나 DB서버가 작업을 수행하는데 전혀 문제가 없다면, 병목이 있다고 판단하기 어렵습니다.
특히 CPU 사용률이 80%인 경우, 응용프로그램의 추가 명령어 수행을 필요로 했다면, 적시에 실행 가능한 상태였고,
80%인 경우도 여전히 프로세서의 유휴 상태가 존재했으며,
프로세서의 추가로 성능이 향상될 것이라고 기대하기도 분명하지 않습니다.
무엇보다도, H/W기술자가 아닌, 서비스 운영 담당자에게는
이러한 병목의 판단과 성능 지연 여부가 중요한 의미를 갖습니다.
그러므로, CPU병목은, 시스템 성능에서 CPU의 처리 지연이 발생한 것의 정의를,
시스템의 핵심기능을 수행하기 위해,
프로세서 용량이 부족한 것인지를 기준으로 판단하는 것이 필요합니다.
이러한 판단을 위해, 앞에서 여러 카운터를 사용해 데이터를 수집하는 방법을 살펴보았습니다.
Processor\%Processor Time (_Total)위에 언급된 모든 카운터는 모두 의미를 담고 있습니다.
Processor\%Privileged Time (_Total) Process\%Processor Time (프로세스명 – W3WP.EXE, SQLSERVR.EXE 등)System\Context Switches/secSystem\System Calls/sec
System\Processor Queue Length
특히 시스템 성능을 모니터링 할 경우 꼭 필요한 요소입니다.
한편으론, 위의 카운터는 2 종류로 나눌 수 있는데, 하나는 상태를 나타내는 정보(사용량)이고,
다른 하나는 지연 여부를 확인할 수 있는 정보(성능지표)입니다.
즉 %Processor Time은 사용률을, Context Switches의 경우는 프로세서의 컨텍스트 변경수를 의미하며,
그 수의 많고 적음을 보게 됩니다.
반면에, Processor Queue Legnth(PQL, 프로세서 처리 대기열의 길이(쓰레드수))는
이러한 지연 여부(처리 지연 발생 여부)를 판단하는데 큰 도움이 됩니다.
엄청난 문자열 연산이나 계산으로 CPU사용률이 높았거나,
또는 잦은 시스템(커널) 루틴의 명령 수행으로 Context Switch가 높았건 간에,
결국은 PQL에 반영됩니다.
즉, PQL이 ‘0’이 아니라면, 프로세서가 너무 바쁜 관계로,
이미 처리할 준비가 되어있는 작업 쓰레드(프로세서가 살펴봐 주기를 바라는 사용자 프로그램)
에 가서 처리를 수행하지 못하는 것이므로, CPU성능병목 판단의 중요한 지표가 됩니다.
정의된 성능병목과 병목을 유발한 원인은 별개의 문제입니다.
프로세서가 병목이라고 해서, 성능 저하나 서비스 장애 원인이
CPU성능이라고 보는 것은, 열심히 일한 프로세서 입장에선 억울할겁니다.
프로세서가 처리할 응용프로그램의 설계된 동작에 직접적인 영향을 받고,
DB의 설계에도 영향을 받으며, 잘못 설치된 드라이버(커널CPU),
잘못 작성한 코드로 업데이트 된 백신 등도 원인이 됩니다.
그러므로, 객관적인 성능 자료를 바탕으로 정리된 분석이 중요합니다.
참고로, 성능 문제가 있을 경우, PerfMon사용을 걱정하는 경우가 있는데,
PerfMon은 참 (1)가볍고, (2)성능에 우려가 있을 때 꼭 실행이 필요한 프로그램입니다.
수집대상(필요한 카운터)과 수집기간, 주기를 주의해서 사용하면 도움이 됩니다.
예를 들어 분석하고 싶은 카운터만 1일 동안,
매 10초 간격 등으로 설정하여 수집하면, 시스템에 큰 부담을 주지 않습니다.
성능 분석을 위한, CPU 관련 카운터 추가 정보
Processor\%Processor Time (_Total)
Processor\%Privileged Time (_Total)
CPU 사용률, 커널 사용률 등은 그 값 자체로 성능분석에 중요한 의미가 있으며,
일시적이 아니라 지속적으로 높은 사용률을 유지하게 되면,
CPU성능이 시스템이 운영하는 핵심 서비스 성능에 영향을 주고 있다고 볼 수 있습니다.
따라서, 시스템(커널) 사용 시간, 응용프로그램 프로세스 별 사용률 등을 종합적으로 보고, 판단합니다.
단일 프로세스의 단일 쓰레드가 CPU시간을 대부분 소비할 경우, 더 빠른 CPU 추가가 결론이 될 수 있습니다.
서버에서는 PQL 값이 더욱 명확하게 프로세서 병목과, 프로세서 추가 필요성을 정의하는데 도움이 됩니다.
Process\%Processor Time (프로세스명 – W3WP.EXE, SQLSERVR.EXE 등)
프로세스 성능 오브젝트 이하의 %Processor Time은 최대값이 100x프로세서수 입니다.
즉, 프로세서가 4개인 경우 400%가 최대값이 됩니다.
CPU는 프로세스라는 논리적인 메모리 공간 보다는,
실제 수행할 명령어를 포함하고 있는 쓰레드를 대상으로 작업을 수행하며,
하나의 프로세스는 여러개의 쓰레드를 포함할 수 있기 때문입니다.
4개의 CPU가 MyApp이라는 프로세스 안에, 4개의 쓰레드만 계속 실행하는 경우,
그 예가 될 수 있습니다. (CPU 100% x 4)
성능 병목의 분석 과정에서, 이 값이 높으면 문제라고 보기 보다는,
핵심 서비스가 프로세서를 잘 활용할 수 있는가의 측면도 중요합니다.프로세서는 기본적으로 메인보드에 있는 칩이라고 봅니다.
CPU를 마치 같이 일하는 동료라고 보고,
IDLE(?)하게 만들어야 잘 설계된 것이라고 생각하진 않습니다.
System\Context Switches/secSystem\System Calls/sec
일반적으로 서버 시스템의 서비스는 단일 쓰레드 응용프로그램보다는
잘 설계된 다중 쓰레드 서비스 프로그램이 매우 유리합니다.
Context Switch는 프로세서가 처리할 명령어셋이 변경/로드되는 경우에 발생하며,
다중 쓰레드 설계로 인해 증가하는 부분보다는, 커널 루틴 호출로 인해 발생하는 경우가 큽니다.
특히 서버의 프로세서가 1-2개인 경우, Context Switch에 의해 병목을 유발하는 경우가 있습니다.
이 경우 CPU 사용률이 낮은데도, PQL은 커지게 될 수 있습니다.
’System’ 성능 오브젝트의 카운터들은 프로세서당 값으로 분석하므로,
프로세서가 4개인 경우, 해당값에서 4로 나눈 값으로 병목을 판단합니다.
예를 들어, Context Switches/sec가 20000인 경우,
CPU가 한 개라면 힘겨운 상황이지만, 4개라면 5000/sec 정도로, 상대적으로 가볍게 볼 수 있습니다.
주로 검색되는 문서에서는 프로세서당 5000개 또는 10000개 이상을 병목으로 보기도 하지만,
과거, 프로세서 속도가 1.X GHz, 2.0GHz에서 테스트 된 결과이기도 해서,
선택적으로 판단할 필요가 있습니다.
System\Processor Queue Length
프로세서당 처리 대기 쓰레드 수가 지속적으로 ‘0’이 아닌 값이면,
프로세서 병목으로 인해 시스템 성능이 지연되는 것으로 판단할 수 있습니다.
CPU 병목 판단의 임계값으로 프로세서당 ‘2’ 이상의 값을 사용할 수 있습니다.
댓글 없음:
댓글 쓰기