성능 모니터는 관리자가 병목 문제나 장애 문제를 파악할 수 있는 가장 보기 좋은 도구다. 보기 좋다는 것은 이해하기 쉽다는 것이고, 프로그램으로 말한다면 고급 언어(High Level Language)인 셈이다. 그렇다면 저수준 언어(Low Level Language)에 해당하는 것도 있을까? 있다. 덤프(Dump)라고 많이 들어봤을 것이다. 이것이 어셈블리와 같이 서버에서 본다면 저 수준에 속한다.
사실 윈도우 서버의 성능 모니터 툴은 용량을 계획할 때 데이터를 추출할 수 있는 좋은 도구지만, 일반적으로는 서버의 장애나 병목을 파악할 때 사용하는 도구로 제작된다. 왜냐하면 성능 모니터의 카운터들이 문제 발생을 파악하는데 기준이 되기 때문이다.
성능 모니터는 컴퓨터→성능 개체→카운터→인스턴스 순으로 세부적으로 들어간다. 많은 카운터들이 병목을 판단하기 위한 자료가 되지만, 몇몇 카운터는 접속 현황이라든지 사용량을 나타내므로 이런 기준들을 잘 조합해서 용량 계획에 대한 데이터 기준을 만들어 낼 것이다.
예를 든다면 이 서버의 접속자가 몇 명이 될 때 서버의 한계가 될 것인가? 하는 기준을 제시한다. 성능 모니터에서 추가하는 개체가 어떻게 구성되고 동작하는지를 알면 조금 더 쉽게 접근할 수 있기 때문에 우선적으로 용량 계획이라는 관점보다 성능 모니터 도구 본연의 임무쪽으로 설명하도록 하겠다.
성능 모니터는 여러 가지 데이터가 복합적인 판단에 의해 결과가 나와야 한다. CPU가 몇 십분, 몇 시간 동안 계속해서 임계치 값이 70∼80% 이상 유지한다고 해서 'CPU가 병목이네'라고 판단하고 CPU를 싱글에서 듀얼로, 또는 4웨이로 확장한다고 해서 만족할만한 성능을 얻을 수 있는 것은 아니다.
CPU 사용률이 임계치값 이상의 사용률을 보이고 있다면 그 원인을 파악해야 하고, 원인 파악은 다른 성능 개체를 통해서 이뤄진다. 하나의 개체가 병목이라고 해당 개체의 사이징(sizing)을 잡고 확장한다면 그것은 잘못된 판단이다. 이 부분은 애플리케이션을 수정해서 해결할 수도 있고, 메모리나 디스크를 교체해서 병목을 해결할 수도 있다. 계획적이고 올바른 사이징은 병목을 예방하는 하나의 방법임을 기억해 두길 바란다.
성능 모니터를 어떻게 설정하는 것이라는 방법론, 즉 툴을 다루는 법에 대해서는 언급하지 않겠다. 그렇게 어렵지 않은 부분이고 설정에 대한 부분은 마이크로소프트 기술 사이트나 여러 방법으로 쉽게 얻을 수가 있다. 어려운 것은 어떤 개체의 어떤 카운터를 설정하고, 어떤 기준으로 그 데이터를 분석할 것이냐 하는 것이다.
용량 테스트 전 성능 모니터 설정 사항
다시 한번 강조하지만 성능 모니터의 개체, 카운터 그리고 인스턴스는 WAS를 수행하기 전에 로그로 설정해 놔야 한다. 그래야 WAS 테스트 환경에서 접속에 대한 성능 로그를 볼 수가 있다. 개체에 대해서는 그 개체가 어떤 방법으로 동작하는지에 대해 설명할 것이다.
개체가 어떻게 돌아가는 지를 알면 서버를 운영하는데도 많은 도움이 될 것이다. 카운터에서는 카운터가 어떤 것이며, 이 카운터의 임계치 값을 명시할 것이다. 용량 계획을 위한 카운터 값은 수집이 목적이지만 병목을 판단해야 하는 카운터 값은 임계치를 알아야 한다. 아무리 찾아봐도 그 카운터의 일반적인 임계치 값에 대해 명시가 안된 것이 있다. 이 부분은 결과물이 나온 후 어느 정도면 해당 카운터의 현재 임계치 값이 얼마인지를 제시한다. 웹서버는 INETINFO와 DLLHOST라는 프로세스가 분석 타겟이 된다. MS SQL은 MS SQL에 관련된 프로세스가 분석될 것이다. 그러면 개체와 카운터에 대해 알아보자.
가상메모리의 원리
일반적인 컴퓨터의 메모리를 지칭하면 보드의 메모리 뱅크에 꽂혀있는 물리적인 메모리, RAM을 지칭한다. 이런 RAM은 속도를 극복하려는 많은 변화가 있었으며, SIMM, DIMM에서 SDRAM 그리고 DDR 방식으로 핀수도 갈수록 많아졌다. 그러나 서버에서 메모리를 지칭할 때면 약간 다른 관점에서 봐야 한다. 물론 클라이언트들이 주로 쓰는 운영체제인 윈도우 프로페셔널이나 XP 같은 경우에도 가상 메모리라고 하는 것이 있지만 이런 운영체제에 대해 가상 메모리가 어떻게 동작을 하는지 사용자들은 별 관심이 없고 알 필요도 없다.
본인의 PC가 어느 순간 느려지거나 이상이 발생하면 그 피해는 자기 자신만 주어지지만 서버에서 그런 현상이 발생하면? 그 영향는 서버를 사용하는 모든 사용자들에게 돌아간다. 이런 이유로 그 서버를 관리하는 사람이면 메모리가 어떻게 운영되는지를 알아야 문제가 생겼을 때 문제 발생 원인과 해결책을 제시해 줄 수 있다. 윈도우 서버의 많은 장애 가 메모리에 기인하고 있는 이유는 애플리케이션 때문이다. 비율로 얘기를 한다면 80% 이상으로 말할 수 있다.
윈도우 서버에서 메모리를 모니터링할 때에는 RAM과 가상 메모리가 같이 모니터링되고 있음을 알아야 한다. RAM의 한 부분으로 운영되는 것이 가상 메모리(PAGING FILE)이고, 이것의 위치는 하드디스크에 있기 때문이다. 메모리의 문제가 생기면 대부분 애플리케이션에서 문제가 발생된다. 간혹 디스크만을 모니터링하고 있다면 디스크의 병목 현상도 볼 수 있다. 이것은 디스크의 성능 문제가 아니고 잘못된 애플리케이션으로 인해 페이지 폴트가 일어나기 때문에 디스크의 병목 현상으로 보이는 것이다.
시스템에 관련된 프로세스들은 주로 RAM에 상주한다. 중요하고 자주 쓰이기 때문에 빠른 처리 속도가 필요하기 때문이다. 그러나 애플리케이션들은 사용자의 필요에 의해 쓰이는 것이고 자주 쓰는 것이 아니기 때문에 RAM에 상주할 필요는 없다.
시스템을 재부팅하고 나서 바로 작업관리자를 띄워서 살펴보자. 자주 보는 그림이기 때문에 그림 삽입은 하지 않겠다. 메모리 사용 내용이라는 그래프 밑에 보면 네 개의 파트가 있다. 이중 실제 메모리라고 하는 것은 RAM을 나타내는 것이며, 부과 메모리라고 하는 것은 가상 메모리를 나타낸다. 메모리 사용 내용이라는 그래프는 부과 메모리라고 하는 가상 메모리의 변화량을 보여주고 있는 것이다.
참고적으로 가상 메모리는 c:에 위치하는 것이 기본이고(관리자에 의해서 C: 아니 다른 파티션으로 변경 가능), 가상 메모리의 크기는 RAM의 1.5배∼3배의 크기로 기본적으로 윈도우 서버가 설정을 하지만 관리자가 변경할 수는 있다. 그러나 권장 사항은 아니다. 가상 메모리를 늘리려면 RAM을 추가하라고 권장하고 싶다.
재미있는 예를 한번 들어보자. A와 B서버 두 대 있다. A서버의 RAM은 1GB이고, B 서버의 RAM은 8GB이다. A서버의 가상 메모리 크기는 1.5∼3배로 설정이 되므로 1.5G∼3G로 설정될까? 맞다. 그렇게 설정된다. B서버의 가상 메모리 크기도 역시 1.5∼3배로 설정이 되므로 12G∼24G로 가상 메모리가 설정이 될까? 아니다 틀린 답이다. 윈도우 서버의 RAM을 8G, 16G, 32G의 RAM을 설정한다고 해도 가상 메모리의 크기는 4G 이상을 못 넘어간다. 윈도우 서버에서는 가상 메모리의 최대 크기는 4G이고, 4G 중 커널용으로 2GB의 공간이 예약, 사용자 모드 프로세스용으로 2GB가 설계돼 있다.
MS DOS를 기억하는 분들이 많을 것이다. 실제 메모리 한계를 640KB로 제한돼서 설계가 됐다. 그때 설계한 사람이 설마 애플리케이션들의 덩치가 그렇게 커질지 간과한 것이다. 새로운 애플리케이션들이 쏟아지면서 메모리 크기가 심각한 문제가 됐다. 그래서 확장 메모리(Extended Memory)를 config와 autoexec에 설정해서 사용했다.
참고적으로 가상 메모리의 사용 크기를 사용자 모드 프로세스용으로 더 할당하고 싶다면 c:boot.ini의 /3GB라는 플래그를 사용하면 커널용으로 1GB, 사용자 모드 프로세스용을 3GB가 할당되고, 이와 같은 설정은 MS SQL, 익스체인지에서 효과를 볼 수 있다. 웹서버는 추천하고 싶지 않다.
이제 가상 메모리가 어떻게 동작하는지 간단하게 살펴보자. 애플리케이션이 로드되면 사용자 파일을 실행하고 난 후 필요한 데이터만 RAM에 남고 나머지는 가상 메모리에 상주한다. 이렇게 구분하는 역할을 담당하는 것이 커널단의 메모리 관리자가 하는 작업이다.
메모리 관리자는 가상 메모리에서 어떤 것이 중요하고 중요하지 않은가를 어떻게 판단할까? 중요하지 않은 것을 버려야 할 상황도 발생할 수 있다. 이럴 때 어떤 기준을 가지고 처리할까? 이 부분은 아래 'Basic algorithm of the Memory'를 참고하면 되겠다.
가상 메모리에 영원하게 상주하느냐? 그건 아니다. 가상 메모리에서 필요한 데이터가 있다면 RAM으로 이동해야 하는데, 이럴 때는 어떻게 처리될까? 프로세스가 '몇 번지(0x80000000)에 있는 데이터가 필요해'라고 메모리 관리자에게 요청을 했는데, RAM의 해당 번지에 데이터가 없다면 이 주소의 데이터는 메모리 관리자에 의해 가상 메모리로 이동한다. 그렇기 때문에 메모리 관리자는 페이지 오류라는 알고리즘을 통해 재빨리 해당 데이터를 프로세스가 요청한 주소로 옮겨 놓는다. 프로세스 입장에서 보면 자기가 요청한 데이터를 RAM에서 가져오는 것으로 보이지만, 실제적으로는 하드디스크에 있는 가상 메모리에서 데이터가 옮겨져 왔다는 것을 여러분은 알 것이다.
컴퓨터의 속도를 비교하면 보통 CPU>RAM>HDD의 순서로 그 속도가 구분된다. 느린 하드디스크에서 데이터를 끌어온다는 것은 컴퓨터의 속도 면에서 아주 손실이 많은 부분이다. 서버를 운영하면서 가상 메모리에서 RAM으로 이동(페이징) 작업을 피할 수는 없지만 그 횟수를 줄인다면 서버 성능의 향상 효과를 크게 볼 수가 있다. 잘못 제작된 ASP나 COM+ 등 기타 애플리케이션이 서버를 다운시키는 것을 자주 봤다. 그 실제의 예를 성능 모니터의 마지막 부분에서 보여주도록 하겠다.
※ Basic algorithm of the Memory
① FIFO(First-In-First-Out) : FIFO는 먼저 들어온 것이 먼저 나간다라는 알고리즘이다. X86 기반의 멀티프로세서 시스템에 적용되는데, 최근에 사용된 시기와 상관없이 RAM에 가장 오래 있던 데이터가 페이징 파일로 이동한다는 것이다.
② LRU(Least Recently Used)와 MRU(Most Recently Used) : LRU는 최근에 사용된 데이터에 사용된 시기를 분석해 한동안 사용되지 않은 데이터를 페이징으로 이동시키는 알고리즘이고, MRU는 가장 많이 사용하는 메모리 영역이다. X86 기반의 단일 프로세서 시스템에 적용된다.
이 두 알고리즘을 통해 최근에 가장 많이 사용하는 RAM 데이터나 최근에 사용된 데이터는 RAM에 존재하고, 그 이외의 메모리 페이지들은 가상 메모리로 이동한다.
메모리 개체 카운터 설정
① Available Bytes(임계값 : 전체 메모리 크기의 5% 이하일 때)
실행중인 프로세스의 작업 설정과 캐시에서 필요로 하는 정보를 취한 다음 남아있는 RAM의 크기를 말한다. 쉽게 말하면 사용 가능한 RAM이 얼만큼 남았는지 알 수 있는 카운터다. 일반적으로 Available Bytes가 적고 메모리/pages/sec가 높다면 메모리를 추가해야 한다. 이 말은 RAM이 사용할 수 있는 공간이 적기 때문에 RAM의 데이터를 가상 메모리로 보내고 프로세스가 호출한 메모리의 페이지를 가상 메모리에서 불러왔기 때문이다. 실제로 사용할 수 있는 RAM의 공간은 0으로, 채워져 있거나 비워있거나 대기중인 메모리 목록에 있는 공간을 합쳐 계산한다. 빈 메모리는 사용할 준비가 된 메모리고, 0으로 채워진 메모리는 다음 프로세스가 이전 프로세스에서 사용된 데이터를 보지 못하도록 0으로 채워진 메모리 페이지다. 대기 메모리는 프로세스 작업 집합(실제 메모리)에서 제거돼 디스크로 라우트됐지만, 다시 호출돼 사용될 수 있는 메모리를 말한다.
② Committed Bytes(임계값 : Committed Bytes In use%로 판단)
RAM에 제휴된 가상 메모리의 크기를 나타낸다. 이 말은 프로세스는 RAM에만 존재하는 것이 아니고 가상 메모리에도 존재한다. 즉 데이터가 디스크로 페이징돼야 하는 경우, 페이징 파일에서 필요한 공간인 RAM의 양을 기록한다. 이 말은 사용중인 메모리이며 다른 프로세스는 사용할 수 없고 고정됐으며 사용되는 메모리량이다. Available Bytes가 크면 Committed Bytes가 작아지고, 반대로 Available Bytes가 작으면 Committed Bytes가 커진다.
③ Page/sec(임계값 : 80 이상)
RAM에서 사용할 수 없는 애플리케이션과 RAM에 다른 페이지 공간을 만들기 위해 하드디스크에서 읽거나 기록해야 하는 애플리케이션을 실행하기 위해 요청된 메모리의 페이지 수를 말한다. Page Faults/sec을 보면 쉽게 이해할 수가 있다. 한번 더 강조한다면 프로세스가 RAM에서 관련 주소를 호출했다. 이것이 RAM에 없다면 가상 메모리에 있기 때문에 메모리 관리자는 가상 메모리가 있는 디스크로 액세스해야 한다. 이 말은 페이징 파일을 사용했다는 말과도 같다. 즉, 초당 페이징 파일을 몇 번 사용했느냐 또는 가상 메모리에서 RAM으로 몇 번 올라오느냐를 말한다. 일반적으로 이 수치는 초당 30이 넘으면 과부하가 온다고 한다. 그러나 이것 하나만 놓고 본다면 잘못된 판단을 불러올 수 있다. CPU의 사용량과 Available Bytes와 연계해 볼 필요가 있다. Available Bytes는 많이 있는데 Page/sec가 많다면 이것은 실제 메모리가 부족한 것이 아니고 애플리케이션이 메모리를 잘못 관리하는 경우라고 볼 수 있다.
④ Page faults/sec(임계값 : 일반적으로 200 이상, 웹서버인 경우 180~300 이상)
프로세스에서 작업 설정의 일부인 RAM을 사용하려고 하지만 찾을 수가 없는 경우, 메모리 관리자는 페이지 오류를 발생시키고 디스크의 가상 메모리에서 다시 불러들이는 경우를 나타낸다. 페이지 오류는 크게 하드 폴트(가상 메모리 액세스를 필요로 하는 경우), 소프트 폴트(RAM에 폴트된 페이지가 있는 위치) 등이 있고 자세한 폴트의 내용은 다음과 같다.
- 메모리에 상주하는 페이지가 아니라 디스크의 페이지 파일 또는 맵파일에 액세스하는 경우
- 대기 중이거나 수정목록에 있는 페이지에 액세스하는 경우
- 커밋되지 않은 페이지에 액세스하는 경우
- 커널 모드에서만 액세스 될수 있는 페이지에 사용자 모드로부터 액세스하는 경우
- 읽기 전용인 페이지에 쓰는 경우
폴트라고 하면 실수를 말하는데, 대부분의 프로세서가 별무리 없이 많은 수의 소프트 폴트를 처리할 수 있다. 그러나 디스크를 액세스하는 하드 폴트의 경우는 심각한 성능 문제를 일으킬 수 있다. 즉, CPU와 메모리의 처리 속도와 CPU와 하드디스크의 속도는 엄청나게 차이가 난다. 하드 폴트가 많이 일어나 디스크의 병목 현상이 일어나고, 이로 인해 CPU가 대기 상태에 놓일 수도 있다.
일반적으로 이 수치가 20이 넘으면 과부하라고 판단해도 된다. 웹서버인 경우에는 180∼300 정도는 안정적인 수치다. 그러나 역시 다른 개체와 연동해서 봐야한다. 페이지란 디스크에 존재하기 때문에 디스크의 입출력에 대한 개체와 같이 연동해서 봐야 한다. 개별적으로 봐서 수치가 4∼5000 단위 이상이면 이것은 메모리 불량으로 봐도 된다. 서버의 모든 구성을 마치고 서비스를 시작하기 직전에 이 카운터값만 돌려서 천 단위 이상이 나온다면 이것은 메모리의 불량이다. 메모리의 불량이라고 해서 시스템이 부팅이 안되는 정도는 아니다. 시스템 운영상에는 전혀 문제가 없어 보이지만 패리티가 깨졌거나 노이즈가 있는 경우에도 가능하다.
⑤ Pool Nonpaged Bytes(임계값 : 4MB 이상)
Pool이란 쉽게 수영장을 생각하면 되겠다. 여기서 풀이란 어떤 공간을 만들어 놓고 사용하기 위한 곳이며 재사용도 가능하다. Nonpaged란 페이지가 되지 않은 메모리 즉 RAM에 존재하는 것이다. 이 말은 가상 메모리로 액세스하지 않고 캐시라는 공간으로(실제적으로는 RAM에 존재함)의 액세스를 말한다. 캐시가 사용되는 이유는 굉장히 급하고 반복적으로 사용되는 케이스고, 이런 것은 가상 메모리 관리자(VMM)가 관리한다. 풀링(Pooling,캐시와 RAM으로의 입력)이 많다면 프로세스의 과부하며 애플리케이션의 수행에 문제가 있다고 볼 수 있다. 일반적으로 윈도우 2000이 설치되면 파일서버 용도로 메모리 구성이 디폴트로 이뤄진다. 이럴 경우 캐시가 메모리 크기의 25%를 사용하기 때문에 물리적인 메모리가 많이 손해본다. 이런 부분은 메모리 구성 조정을 통해 캐시의 크기를 줄일 수가 있다.
⑥ Pool Paged Bytes(임계값 : 사용량 파악)
디스크에 있는 가상 메모리를 페이징 파일이라고도 부른다. 페이지됐다는 얘기는 RAM과 가상 메모리를 이동할 수 있다는 얘기다. 앞서 설명한 Pool Nonpaged Bytes는 고정돼 사용된다는 것이고, Pool Paged Bytes는 페이지로 사용되지 않고 있을 때 메모리 관리자에 의해 디스크에 쓸 수 있는 개체에 대한 시스템 메모리(운영 체제가 사용하는 실제 메모리) 영역을 말한다.
⑦ Commited Bytes In Use(임계값 : 70 이상)
가상 메모리의 사용량 한계를 살펴볼 목적으로 이 개체를 추가하면 된다. 가상 메모리가 한계에 다다르면 윈도우 서버는 가상 메모리 공간이 부족하니 확장하라는 경고 메시지가 뜬다. 이런 사용량 파악이 목적이며 Commit Limit에 대한 Commited Bytes의 비율이다. Commit Limit가 1000이고 Commited Bytes가 300이면 30%를 사용하고 있다고 표시된다. 일반적으로 페이징 파일의 크기는 RAM의 1.5배가 권장사항이다. 그러므로 가상 메모리가 이 크기에 다다르면 메모리 확장을 고려해야 한다.
⑧ 캐시 Faults/sec(임계값 : 100 이상)
컴퓨터를 접하다 보면 버퍼(buffer)와 캐시(cache)라는 용어를 많이 접하게 된다. 버퍼는 말 그대로 완충기 역할을 한다. 캐시가 속도를 빠르게 하는 목적이라면 버퍼는 속도를 떨어뜨리지 않고 유지할 수 있게 하는 역할을 하는 것이다. 버퍼는 하드웨어와 프로그램 양쪽에 모두 존재하며, 속도가 다른 하드웨어 장치들, 우선 순위가 다른 프로그램의 프로세스들에 의해 공유되는 데이터 저장소를 말한다. 버퍼는 각 장치나 프로세스가 상대방에 의해 정체되지 않고 잘 동작할 수 있도록 해주는 역할을 맡는다. 캐시는 데이터를 임시로 저장해두는 장소를 말한다. 프로그램적으로는 불가능하며 하드웨어적으로 존재한다. L2, L3 캐시 메모리라는 것을 들어보고 직접 보기도 했을 것이다. RAM에서 데이터를 하드디스크에서 가져오려고 하면, 서로의 속도 차이 때문에 캐시가 RAM 안에 존재한다. 여기에 해당 데이터가 존재한다면 가지고 올 수 있다. CPU에 캐시 메모리라는 것이 있는데 RAM까지 가기 바쁘니 캐시 메모리에 있다면 여기서 가지고 올 수 있다. 이런 이유로 캐시라는 것이 존재하고 이에 대한 성능 카운터가 윈도우 서버에 존재하는 것이다.
캐시 Faults/sec은 찾아본 페이지가 파일 시스템 캐시에 없고, 메모리에 있거나(soft fault) 디스크에 있었던(hard fault) 오류 수를 나타낸다. 파일 시스템 캐시는 애플리케이션이 최근에 사용한 데이터를 저장해두는 실제 메모리의 일부 영역이므로 잘못된 애플리케이션은 이 카운터 값을 높일 것이다. 이 카운터에 대한 임계치 값은 없다. 그러나 Available bytes 5% 이하이고, page faults/sec이 임계치 값이 높고 cache faults/sec이 평상시보다 높게 수치가 기록되면 100% 메모리 부족이나 애플리케이션의 오류라고 적용해도 된다. 서두에서도 설명했지만 윈도우 서버 성능 모니터는 복합하게 볼 필요가 있다고 한 것을 기억하자.
⑨ 캐시 Bytes(임계값 : 사용량 파악이 목적)
이제 캐시가 무엇을 하는지 알 것이다. 그러나 성능 모니터에서의 캐시를 본다면 이 카운터가 실제로 시스템 캐시 작업 세트를 나타내지 않는다는 것이다. 즉, 카운터 한 개가 시스템 캐시의 크기를 나타내는 것이 아니고, 4개의 카운터가 합쳐져서 캐시 Bytes라는 카운터 값을 나타내는 것이고 4개의 카운터 중 한 개가 우리가 일반적으로 말하는 RAM의 캐시를 얘기를 한다. 4개의 카운터는 다음과 같다.
- System Cache Resident Bytes : 이 카운터가 4개 중 한 개의 카운터, 실제 메모리에 있는 파일 시스템 캐시로부터의 바이트 수를 말한다.
- System Driver Resident Bytes : 장치 드라이버가 현재 사용하고 있는 페이지로 나눌 수 있는 실제 메모리의 바이트 수를 나타낸다. 이것은 드라이버의 작업 집합(RAM 영역)이다.
- System Code Resident Bytes : 사용하지 않을 때 디스크에 쓸 수 있는, 실제 메모리에 현재 있는 운영체제 코드의 바이트 수를 나타낸다.
- Pool Paged Resident Bytes : 페이지된 풀의 현재 크기를 바이트로 나타낸다. 페이지된 풀은 사용되지 않고 있을 때 디스크에 쓸 수 있는 개체에 대한 시스템 메모리(운영 체제가 사용하는 실제 RAM) 영역이다.
캐시를 이루는 카운터가 어떤 것인지 간단하게 설명했다. 설명하는 동안 작업 세트(working set)라는 말을 몇 번 언급했다. 이는 물리적(RAM)으로 정착된 프로세스의 가상 주소 공간의 부분 집합으로, RAM에 상주하는 가상 페이지의 하위집합을 설명하기 위해 사용하는 용어다. Page Faults/sec을 설명을 하면서 페이지 폴트가 왜 일어나는지를 설명했다. 디스크의 가상 메모리를 액세스하는 것이 메모리 관리자가 한다고 했지만 엄밀하게 얘기하면 작업 세트 관리자가 수행하는 것이다. 작업 세트 관리자가 가상 메모리의 주소 공간을 가지고 있기 때문에 작업 세트 관리자를 통해 가상 메모리에서 RAM으로 데이터가 이동할 수 있는 것이다.
⑩ Page Read/sec(임계값 : 5 이상)
이 카운터는 하드 페이지 폴트를 해결하기 위해 디스크가 읽혀진 횟수를 나타낸다. Page Faults/sec이 소프트 폴트와 하드 폴트 두 가지를 다 포함하기 때문에 이 카운터로 하드 페이지 폴트의 비율을 알 수 있다. 만약 이 수치들이 낮을 경우 웹서버는 request에 대해 빠르게 응답할 것이고, asp queued에도 2 이상의 수를 기록하지 않을 것이다. Page Faults/sec이 높다고 무조건 애플리케이션에 잘못이 있는 것은 아니다. 하드 폴트가 많은 것이 성능을 저하시키는 것이고, 이것은 잘못 설계되거나 수행되는 애플리케이션 때문이다. 애플리케이션에서의 문제가 아니라고 판단이 되면 RAM을 증설해야 한다.
⑪ Page Input/sec(임계값 : 5 이상)
이 카운터는 하드 페이지 폴트를 해결하기 위해 디스크로부터 읽어들이는 페이지들의 총 개수를 나타낸다. Page Faults/sec과 Page Read/sec을 참고하면 된다.
CPU 카운터에 대한 설명
시스템 성능 모니터의 CPU 카운터를 보면 어디서나 늘 임계치는 70∼80% 이상으로 잡고 있다. 이 말은 프로세스 하나가 계속적으로(어떤 일정한 시간은 없지만 10초 이상으로 봐도 된다) CPU 사용율을 70∼80% 이상 사용하고 있다는 말이다. 이때의 해결책은 메모리에서와 마찬가지지만 우선 어떤 프로세스가 CPU 사용률이 많은지 파악해야 하고, 다른 카운터와의 연관관계(디스크 입출력 문제, 페이징 발생 문제 등)를 따져서 이것이 정말 CPU의 병목 현상인지, 아니면 다른 애플리케이션으로 인한 CPU의 병목 현상인지 파악해야한다. 종종 백도어나 웜 등으로 인해 시스템의 장애 현상을 겪는 경우도 있다. 여기서 원인 파악을 제대로 못하고 단지 CPU의 병목이기 때문에 CPU를 듀얼로 확장한다거나 4웨이로 확장 작업을 마쳤다고 하더라도 원하는 만큼의 성능 결과를 얻지 못할 것이다. 수치적으로 환산해서 얘기한다면 100%의 만족감에서 5% 정도의 만족감을 얻을 수도 있다.
그래서 어디가 잘못된 것인가를 파악하는 게 가장 중요한 포인트고, 문제는 주로 원인이 되는 프로세스가 어떤 폴링 작업을 하고 있거나, 루프에 빠져서 허덕이면서 헤어나오지 못하는 현상이 다반사다. 현재 이 연재의 주제는 용량 계획이기 때문에 이런 부분도 같이 다뤄야 한다는 점을 충분히 고려해야 한다.
대부분의 성능 모니터 관련 글을 보면 높은 CPU 사용률에 포커스를 맞춰 정보를 알려 주고 있으나 낮은 CPU의 사용률도 성능 모니터의 대상이 된다는 것을 알아두자. MS SQL의 경우 잠금 경합이 발생하는 경우, 생산적인 작업이 발생하지 않는다면 시스템 CPU 사용량이 0%에 이를 수가 있다. 매우 낮은 전체 성능과 낮은 CPU 사용량을 보이고 있다면 이것 또한 애플리케이션의 어디에선가 병목현상을 보이고 있는 것이고 이것을 찾아서 해결해야 한다. 다만 이는 웹 접속자나 MS SQL의 접속자가 많다는 가정하에서다. 접속자가 없거나 애플리케이션이 쓰이지 않는다면 그것은 당연히 CPU 사용률이 0이어야 한다. 높아도 안되고 낮아도 안된다고 하니 혼란스러울 수도 있으나, 그래도 하다보면 재미가 솔솔 붙을 것이다.
※ IIS가 사용하는 CPU의 개수는?
윈도우 2000의 IIS5.0은 2∼4개까지의 프로세서를 사용하도록 설계돼있다. 그럼 MS SQL은? 운영체제가 지원하는 만큼 사용할 수 있다. 데이터센터가 얼마나 많은 CPU를 지원하는지 알아보면 그것이 한계라고 보면 된다. MS SQL이 엔터프라이즈 버전이어야만 한다.
① %Processor Time (임계값 : 70∼80 이상)
시스템이 사용하는 전체적인 CPU 양을 나타낸다. 일반적으로 70% 이상이 사용되고 있다면 과부하라고 판단된다. 멀티 프로세서가 장착된 컴퓨터에서 불균형 현상을 찾아내기 위해 %Processor Time 카운터의 인스턴스를 전체로 하지말고 0, 1을 따로 설정한다면 CPU 사용률을 각각 볼 수 있다.
② %User Time(임계값 : 80 이상)
수행되고 있는 애플리케이션이 사용하고 있는 CPU 사용률
③ %Privileged Time(임계값 : 80 이상)
시스템이 사용하고 있는 CPU 사용률
이 세 가지 설명된 값은 전부 CPU의 사용량과 관계가 있다. 하나는 시스템의 전체적인 사용량이고 그 전체적인 사용량에서 시스템이 사용하느냐, 애플리케이션이 사용하느냐의 세부 분석이 있다. 이 값을 볼 때는 서로 관계를 지어서 봐야 하는데, 예를 들어서 Processor Time이 30을 기록하고 있다. 이때 User Time이 50을 기록했다면 이것은 Processor의 30에 대한 50을 얘기하는 것이다. 이 말은 Privileged Time과 User Time은 Processor Time의 값을 전체 100으로 놓고 구분한 값이다.
④ Interrupts/sec(임계값 : 7000 이상)
프로세스가 매 초마다 받아 처리한 하드웨어 인터럽트의 평균 수를 나타낸다. 인터럽트가 많다는 것은 애플리케이션의 CPU 사용률이 그만큼 높다는 것이고 CPU의 대기가 그만큼 많아진다는 것이다. 하드웨어적인 측면에서 본다면 아주 과도한 인터럽트가 발생하는 경우는 잘못된 장치 드라이버를 사용하고 있는 경우에도 발생한다. 프로세스가 매 초마다 받아 처리한 하드웨어 인터럽트 평균수를 표시한다. 여기에 DPCs는 포함되지 않고 따로 계산되고, 이 값은 시스템 클럭, 디스크 드라이버, 데이터 통신 회선, 네트워크 인터페이스 카드, 기타 주변 장치 등 인터럽트를 만드는 장치의 활동을 표시한다.
⑤ %Interrupt Time(임계값 : 5 이상)
프로세스가 하드웨어 인터럽트를 받아 처리하는 데 소모한 시간의 백분율을 나타낸다. 이 값은 시스템 클럭, 디스크 드라이버, 데이터 통신 회선, 네트워크 인터페이스 카드, 기타 주변 장치 등 인터럽트를 만드는 장치 활동의 간접 표시기이다. 이런 장치는 일반적으로 작업을 완료하거나 주의를 요할 때 프로세서를 인터럽트한다. 인터럽트 동안 일반 스레드 실행은 잠시 중단된다. 대부분의 시스템 클럭은 백그라운드 인터럽트 활동을 만들면서 매 10 밀리초마다 프로세서를 인터럽트한다.
⑥ %DPC(Deffered Procedure Calls) Time(임계값 : 사용량 참고)
% DPC(표준 인터럽트보다 낮은 우선 순위로 실행되는 인터럽트) Time은 샘플 간격 동안 유예된 프로시저 호출(DPCs)을 받아 처리하는 데 소비한 시간을 나타낸다. DPC는 특권 모드에서 실행되므로 % DPC Time은 % Privileged Time의 구성 요소다. Interrupts/sec과 %DPC Time 카운터를 계산하면, 인터럽트와 연기된 프로시저 콜 즉, DPC에 대해 프로세서가 얼마나 많은 시간을 소비했는지를 나타낸다.
댓글 없음:
댓글 쓰기