[서버용량계획하기 4] 윈도우 서버 용량 계획하기

[서버용량계획하기 4] 윈도우 서버 용량 계획하기

지난 호에서는 성능 모니터를 통해 메모리와 CPU에 어떤 카운터를 설정해야 하는지, 또 어떤 기준으로 데이터를 분석해야 하는지 알아보았다. 이번 호에는 지난 호에 이어 메모리와 CPU 외에 다른 개체들의 카운트 설정 방법도 알아보도록 하자.

 

지난 연재에 이어 성능 테스트 환경을 통한 성능 모니터의 로그 결과물을 토대로 서버 용량의 한계가 어디까지인지, 어느 시점에서 메모리와 CPU, 하드디스크, 혹은 RAID 도입을 결정해야하는 지 알아보자. 우선 메모리와 CPU의 카운트 설정 방법에 이어, 여러 개체의 성능 카운터 설정에 대해 설명하도록 하겠다.

 

 

PhsicalDisk

디스크에서 가장 중요한 것은 디스크의 I/O다. 기본적인 서버의 데이터 입출력과 윈도우 서버(기타 다른 서버 운영체제)는 가상 메모리(Paging File)를 가지고 있는데, 가상 메모리는 하드 디스크에 위치를 해야하기 때문에 디스크의 입출력 문제가 중요하다.

그럼 왜 서버 운영체제는 가상 메모리를 디스크에 두고 있는지 궁금할 것이다. 윈도우 서버의 애플리케이션 프로세스가 모두 RAM에 상주한다면 비용도 비용이지만 수용하지 못할 것이다.

현재 테스트 서버로 준비된 서버는 하는 일이 없다. 앞으로의 결전(?)을 대비해 숨고르기를 하고 있는 중이다. 이럴 때 가상 메모리는 얼마 사용하지 않게 된다. 현재 약 100MB 정도 사용 중이고 최고 한도는 약 1.2GB, 최소 크기는 768MB가 잡혀 있다. 이 가상 메모리의 최대가 1.2GB로, 이 크기는 늘어날 수 있지만 늘리는 것을 권장하고 있지 않다. 윈도우가 가상 메모리를 늘려서 사용하면 CPU의 컴퓨팅 사용량을 많이 차지하기 때문에 추천하지 않고, 이럴 때는 메모리를 늘리라고 권장한다. 이렇게 최대 한도까지 다다른다면 그것은 한마디로 디스크의 입출력이 빈번하게 일어나서 디스크의 병목 현상도 같이 야기하게 된다는 것이다. 이것은 잘못된 페이징 작업으로 디스크에서 RAM으로 데이터가 올라오는 하드 페이지 폴트 오류 때문에 발생할 수가 있는데, 이것을 단지 디스크의 병목으로만 판단해 디스크를 좀더 빠르게, 그리고 가상 메모리도 완전히 다른 물리적 디스크에 독단적으로 쓴다해도 CPU와 같이 개선된 성능을 기대하기는 힘들다.

역시 애플리케이션을 수정한 후 그래도 원하는 성능이 안나온다면 한 개의 디스크를 가상 메모리를 위해 사용하면 보다 개선된 성능을 기대할 수가 있다. 그 이외의 카운터는 이런 병목 현상을 판단하거나 용량 계획에 대한 기초 자료가 될 수 있다.

디스크 성능 카운터를 다루다 보면 DISKPERF라는 명령어를 볼 수 있다. 이 명령어를 통해 시스템 성능 모니터를 사용해 볼 수 있는 카운터의 종류를 제어할 수 있다. DOS 창에서 'DISKPERF /?'라고 입력하거나 '윈도우 서버 도움말 → 색인'에서 찾아보면 쉽게 그 명령어를 이해할 수 있다.

DISKPERF 명령어를 적용하기 전에 성능 카운터를 열어 성능 개체를 보게 되면 PhysicalDisk라는 개체는 보이지만 LogicalDisk라는 개체는 볼 수 없다. 윈도우 서버를 설치하고 나서 디폴트로 올라오는 개체 값이 PhysicalDisk 개체다. DISKPERF 명령을 통해 LogicalDisk를 추가할 수가 있다. 여러 가지 명령어가 있겠지만 'DISKPERF /Y'라고 하면 재부팅 후 적용된다는 메시지가 나오고, 재부팅을 하고 난 후 성능 모니터의 성능 개체를 보면 LogicalDisk라는 개체가 생긴 것을 알 수 있다.

사실 PhysicalDisk 개체와 LogicalDisk의 성능 개체 각 각의 카운터 값은 틀린 것이 없다. 단지 인스턴스를 나타내는 방식이 틀리다는 것이다. PhsicalDisk의 구조는 두개의 디스크를 갖고 있다. 물리적 ID 0번 디스크에 C:\ 와 F:\가 할당됐고, 물리적 ID 1번 디스크에 D:\와 E:\가 할당돼 있다는 것을 나타낸다. 적용 후의 LogicalDisk를 보면 번호는 C:\, D:\, E:\, F:\가 나란히 배열돼 있다. 순수하게 논리적인 구조 관점으로 바라 본 것이다. 사실 PhysicalDisk로 어느 정도의 디스크 병목이 어디서 일어나는지 판단할 수 있지만, 보다 세밀하고 정확하게 적용하고 그 병목이 어느 파티션에서 일어나고 있는지 파악하고 싶다면 LogicalDisk 개체의 카운터를 같이 설정해 놓으면 보다 정확하게 알 수 있다.

필자가 경험했던 디스크 성능 문제를 간단히 소개하겠다. E업체로부터 현재 웹 서버에서 이미지의 로딩이 느리다는 문의가 들어 왔다. 이미지는 웹 서버 로컬에 저장된 것을 로딩하는 것이 아니고 다른 이미지 서버에서 가져 오는 것이다. 해당 웹사이트를 열어 이미지를 로딩해 봤더니 많은 양의 이미지가 있지만 이미지가 위에서부터 아래 방향으로 순차적으로 하나 두개씩 로딩되고 있는 병목 현상이 눈으로 보이고 있다.

이런 것이 눈으로 확인될 정도라면 서버에서는 엄청난 성능 저하가 일어나고 있는 경우다. 또 하나 조금 특별한 상황이라면 로컬에서 로딩하는 것이 아니고 네트워크를 통해 로딩하는 것이기 때문에 네트워크 문제도 고려해야 한다. 네트워크 쪽으로는 패킷 손실이 일어나지 않나 불필요한 트래픽이 실리지 않나를 점검했고, 성능 모니터에서 네트워크에 대한 부분도 예의 주시했다. 여러 가지 성능 개체를 걸어 놓고 판별한 결과, 이미지가 저장돼 있는 디스크의 병목현상으로 확연하게 나타났다.
따 라서 필자는 두 가지 대안을 제시했다. 디스크 어레이를 사용해 데이터의 안정화와 성능향상을 꽤하는 것과 서버를 한대 더 준비해 분산 환경을 사용하라고 제안했다. 고객사는 RAID를 선택했고 레벨은 0+1을 선택했다. 디스크 재구성이기 때문에 재설치는 불가피하다. 재설치 후 웹서버의 이미지 로딩이 원하는 만큼 나왔고, 이미지 서버의 성능도 크게 향상됐다. 사실 직감만으로 이런 작업을 하는 것은 도박과 같다. 성공하면 쾌감을 느끼고 직감에 대해서 신뢰가 가겠지만 만약 실패한다면 처음부터 다시 시작해야 한다.

① %Disk Time(임계값 : 90 이상)
현재 디스크 전송량(읽기+쓰기)을 시간으로 나타낸다. 디스크의 전송속도는 bps이기 때문에 속도 단위를 8로 나눠야 한다. Disk Time이 높고(임계값 이상) Current Queue Length도 높다면 디스크의 I/O 문제로 봐야 한다. 가상 메모리가 위치해 있는 물리적 디스크에 대한 값도 주의 깊게 모니터링한다. 이 값이 증가하면 가상메모리의 용도를 점검하고 메모리를 추가하도록 한다. 임계값 이상이면 과부하며, 별도의 디스크를 구입해 시스템 데이터, 사용자 데이터, 가상 메모리 데이터를 물리적으로 구분하거나 RAID 도입을 고려해야 한다.

② Current Disk Queue Length(임계값 : 2 이상)
디스크를 읽기 위해 대기열에 대기하고 있는 내용들의 수를 나타낸다. 디스크 병목을 판단하는데 중요한 모니터링 자료가 된다.

③ Disk Bytes/sec(임계값 : 사용량 파악)
쓰기 또는 읽기 작업 동안 디스크로(또는 디스크에서) 전송되는 양으로, 얼마나 많은 디스크의 입출력이 발생하는 지를 나타낸다. 이 값은 초당 얼마나 많은 데이터가 디스크로 입출력하는지 기준이 되는 모니터링 자료다.

④ Avg. Disk Bytes/Transfer(임계값 : 사용량 파악)
Avg. Disk Bytes/Transfer는 읽기 또는 쓰기 작업 동안 디스크로(또는 디스크에서) 전송되는 평균 바이트 수를 나타낸다. Disk Bytes/sec가 초당 전송률을 나타낸다면 이것은 평균값이다.

⑤ %Idle Time(임계값 : 10이하)
idle의 영어적인 뜻은 '쓰이고 있지 않는'이다. 작업관리자에 봐도 system idle process라는 것이 있고 서버가 쓰이고 있지 않고 한가하다면 이 값은 늘 높게 마련이다. 모니터링 간격동안 디스크의 유휴(쓰이고 있지 않는) 상태의 값을 나타낸다.

⑥ %Disk Read Time(임계값 : 사용량 파악)
% Disk Read Time은 선택한 디스크 드라이브가 읽기 요청을 처리하는데 사용된 시간의 백분율을 나타낸다. Read와 Write를 조합을 해서 %Disk Time와 함께 살펴보면 답이 나온다.

⑦ % Disk Write Time(임계값 : 사용량 파악)
% Disk Write Time은 선택한 디스크 드라이브가 쓰기 요청을 처리하는데 사용된 시간의 백분율을 나타낸다.

⑧ Avg. Disk sec/Read(임계값 : 사용량 파악)
읽기 작업에 소요된 평균 시간(밀리초)을 나타낸다. 오래 지연되는 읽기 작업은 디스크가 과다하게 사용된다는 것을 나타낸다.

⑨ Avg. Disk sec/Write(임계값 : 사용량 파악)
읽기 작업에 소요된 평균 시간(밀리초)을 나타낸다. 오래 지연되는 쓰기 작업은 디스크가 과다하게 사용된다는 것을 나타낸다.

※ %Free Space 카운터
카운터의 이름에서 보다시피 여유 공간을 체크하고 있는 카운터이다. 간혹 디스크의 공간이 모자라 장애를 일으키는 경우가 있는데 이 카운터를 설정을 해놓고 여유 공간을 체크하면 도움이 될 것이다.

 

 

네트워크 인터페이스

IT 분야에서 네트워크가 가장 큰 규모가 아닐까 한다. 네트워크 → 서버 → 응용 프로그램 순으로 동작한다고 봐도 네트워크는 큰 범위다. 예전에 한국에서 IT 붐이 일고 시스코 장비 관리자들이 많은 연봉을 받으며 일했다고 들은 적이 있다. 현재는 워낙 공급이 많아서 예전 같지 않다고 한다. 님다 바이러스(Nimda Virus) 이후 네트워크 관리자들의 보안에 대한 인식도 한층 높아진 것 같다. 네트워크 관리자만 그럴까? 서버 관리자도 마찬가지다. 바이러스, 웜, 백도어(예전에는 바이러스라는 것으로 통일 됐지만)가 그 방법이 갈수록 악랄해지고 있다. 윈도우98 시절 CIH 바이러스가 PC의 하드디스크를 통째로 포맷을 한다고 해서 뉴스에도 나온 것으로 기억한다. 예전 바이러스는 감염되고 자기 자신만 피해를 줬지만 님다 이후로는 개인 뿐만 아니라 네트워크 대역을 스캔해 가며 감염시켰고, 님다를 치료하려면 일단 네트워크를 단절해야 한다. LAN을 연결 시켜놓고 치료해도 소용이 없었다. 이렇게 서버 투 서버로 전파가 되던 것이 이제는 패킷을 무작위로 날려 라우터를 죽이려고 덤벼든다. 기발한 발상이다. 네트워크가 단절되면 서버가 무슨 소용이랴. 무작위로 패킷을 보내 라우터의 CPU나 메모리 사용률을 높여 라우터를 다운시키려고 하는 것이다. 이제 이런 것들은 파이어월이나 플로우스캔, MRTG를 통해 패킷의 움직임이나 성향을 파악해 바로 조치 할 수 있다.
윈도우 서버 성능 모니터링에서 네트워크 모니터링 부분은 사용량을 파악하기 위한 것이지 패킷 분석은 아니다. 패킷을 들여다보고 싶다면 윈도우 서버에 내장된 네트워크 모니터 도구나 이더리얼 등의 제품을 설치해 사용해야 한다. 프로토콜의 기본, 네트워크 구성 등 기본적인 네트워크를 알면 서버를 운영하는데 틀림없이 도움이 된다.

여러 개의 LAN 카드를 쓰고 있는 멀티홈 환경이라면, 해당 LAN 카드에 대해 모니터링을 걸어놔야 할 것이다. 네트워크 인터페이스의 카운터는 사용량을 파악하기 위한 것이기 때문에 임계값은 없다. 임계값이라면 LAN 카드가 지원하는 최고속도의 80% 정도로 생각하면 된다.

① Bytes Total/sec
이 카운터는 해당 서버의 LAN 카드의 모든 네트워크 프로토콜의 송수신 바이트를 초당 사용량으로 나타낸다. 접속자가 많지 않은데 이 사용량이 높다면 웜을 의심해 보기 바란다. 네트워크의 병목을 판단하려면 이 카운터 값과 Current Bandwidth를 비교해 판단해야 한다. 일반적으로 네트워크의 증가분을 고려해 50% 정도의 여유분을 갖고 있어야 한다. CPU, 메모리가 여유있음에도 네트워크 사용량이 많다면 커넥션쪽의 문제를 파악해야 한다. 여기서 주의할 점은 네트워크에서는 비트 단위이고 성능 모니터에서는 바이트이기 때문에 네트워크 어댑터의 대역폭을 바이트로 표시하기 위해서는 8로 나눠야 한다.

② Bytes Sent/sec
초당 서버에서 외부로 나간 전송량을 나타낸다. Bytes Total에서 Bytes Sent를 빼면 Bytes Received/sec가 나온다. Bytes Received/sec 추가 여부는 독자들에게 맡긴다.

③ Current Bandwidth
Current Bandwidth는 LAN 카드의 현재 대역폭을 각 초당 비트(BPS)로 추정한 값이다. 대역폭이 다양하지 않거나 값을 정확히 추정할 수 없는 인터페이스일 경우, 이 값은 명목상의 대역폭을 나타낸다. 이 카운터 값과 Bytes Total/sec 값을 비교한다면 여유분의 네트워크 사용량을 파악할 수 있다.

Acitve Server Page

ASP가 사람들에게 윈도우 서버를 많이 알게 하는데 공헌한 점이 있다고 생각한다. 그러나 ASP에서 늘 문제가 되는 DB 연결, 잘못된 LOOP는 한방에 서버를 가볍게 죽인다. 아주 잘 설계된 ASP 코드는 비싼 서버 10대가 부럽지 않다. 닷넷이 아무리 훌륭하다고 할지라도 기본 설계 방침을 벗어난다면 이름값 못하는 것처럼 말이다.

① Request Queued(임계값 : 40 이상)
큐에서 서비스를 기다리는 중인 요청의 수를 나타낸다. 이 수치가 5 이상 오르면 일단 병목으로 의심해 본다. Web services\Current Connection이 500 이상이고 이 수치가 몇 십을 기록하면 ASP 코드가 무겁다고 판단된다. 또한 커넥션에 상관없이 큐가 40 이상이면 ASP가 무겁다고 판단된다.

② Request/sce(임계값 : 사용량 파악)
초당 ASP가 실행되는 수를 나타낸다. 이 수치가 아무리 많아도 Request Queued에 쌓이지 않는다면 별 무리가 없다. 이 말은 ASP 코드가 바로 수행돼 대기열이 없기 때문이다. 만약 이 카운터가 서버의 트래픽이나 접속자가 많은 시간에 낮은 수치를 보인다면 애플리케이션은 병목 현상을 초래하고 있는 것이다.

③ Request Excution Time(임계값 : 사용량 파악)
가장 최근 ASP 요청을 실행하는 데 걸리는 시간(단위:밀리초)을 나타낸다. ASP의 수행 시간을 판단하는 자료가 된다.

④ Request Excuting(임계값 : 1 이상)
현재 실행 중인 ASP 요청의 수를 나타낸다

⑤Session Current(임계값 : 사용량 파악)
서비스 받고 있는 현재 세션의 수를 나타낸다.

⑥Errors/sec(임계값 : 5 이상)
초 단위 당 발생한 오류의 수를 나타낸다.

⑦ Request Wait Time(임계값 : 1 이상)
가장 최근 요청이 큐에서 대기하는 시간을 나타낸다.

⑧Request Not Authorized(임계값 : 5 이상)
액세스 권한이 불충분해 실패한 요청의 수를 나타낸다. 액세스 권한이 없다면 그것은 IIS에서 권한 설정과 폴더에서의 권한 설정을 점검해야 할 것이다. 자료를 업로드해야 한다면 업로드 프로그램을 이용해 해당 폴더와 IIS 사이트에서 쓰기 권한이 있어야 파일이 서버로 업로드될 것이다. 이런 실패가 있다면 기록될 것이다.

⑨ Request Not Found(임계값 : 5이상)
찾지 못한 파일에 대한 요청의 수를 나타낸다. 이 부분은 ASP에 문제가 있는지 없는지를 간접적으로 판단할 수가 있다. 이 카운터 값이 기록되면 웹로그를 이용해 해당 연결이 어떻게 잘못됐는지를 찾아내야 한다.

⑩ Request Rejected(임계값 : 5이상)
요청을 처리하기에 리소스가 충분하지 않아서 실행되지 않은 총 요청의 수다. 500/sever too busy라는 메시지를 본적이 있을 것이다. 이런 현상이 발견하면 나타나는 카운터값이다.

⑪ Session Timed Out(임계값 : 5이상)
시간이 초과한 세션의 수를 나타낸다. 소스에서 세션 값을 늘일 수도 있고 IIS에서도 늘일 수 있다. 이에 해당하는 카운터 값들이다.

⑫ Transaction Pending
처리 중인 트랜잭션의 수를 나타낸다. 이 트랜잭션 처리의 데이터를 기준으로 용량 계획에 대한 데이터가 나오게 된다.

웹 서비스

① Current Connections(임계값 : 사용량 파악)
이 카운터값은 현재 웹 서비스를 사용해 연결된 수를 나타낸다. 중요한 것은 이 카운터값과 함께 ASP에 대한 사항을 같이 봐야 한다는 것이다. 서로 밀접한 관계가 있기 때문이다. 또한 웹 서버로 이용한다면 접속자가 몇 명이고 서버의 여러 가지 환경을 고려해 몇 명의 사용자가 접속하고 있을 때 한계인지 기준이 될 것이다. 역시 이 카운터 하나만으로 데이터를 산출하는 것이 아니고 CPU, RAM, 하드디스크의 카운터 값과 조합해야 한다.
 
② Connection Attempt/sec(임계값 : 사용량 파악)
웹 서비스를 사용해 연결을 시도하는 비율을 나타낸다. 용량 계획에 필요한 데이터다.

③ Get Requests/sec(임계값 : 사용량 파악)
이 카운터와 Post Requests/sec의 값은 서버의 두 가지 HTTP 요청이 수행되는 속도를 나타낸다. Post 요청은 일반적으로 폼에서 사용되며 ISAPI(ASP 포함) 또는 CGI로 전송되고 Get 요청은 거의 모든 브라우저의 요청을 나타내고 정적파일, ASP 및 기타 ISAPI, CGI 요청 등을 포함한다. 이 카운터값은 사이트의 알반 로드 특성을 이해하는데 많은 도움이 된다.

④ Not Found Errors/sec(임계값 : 10 이상)
요청한 문서를 찾지 못해 서버를 만족시킬 수 없는 요청 때문에 생긴 오류 비율을 나타낸다. 일반적으로 HTTP 404 Not found 오류 코드로 클라이언트에게 보고된다.

⑤ Maximun Connections(임계값 : 사용량 파악)
최대 연결은 웹 서비스를 사용해 동시에 연결할 수 있는 최대 연결 수를 나타낸다. 용량 계획에 필요한 데이터다.

시스템

①Processor Queue Length(임계값 : 2 이상)
이 카운터값은 CPU가 연산하기 위해 대기열에 대기하고 있는 수치를 나타낸다. 일반적으로 이 값이 2 이상이면 과부하로 본다. 이 값을 볼 때에는 Processor Time과 같이 연동해 본다. 이 값이 높고 CPU 사용량도 70 이상이면 이것은 CPU 업그레이드를 고려해야 하지만, CPU 사용량이 부하인 70% 이상이라도 Queue Length가 낮다면 괜찮다. 이는 CPU 수행속도가 기다림 없이 원할하게 이뤄진다는 말과 같다.

② Context Switches/sec(임계값 : 사용량 파악)
이 카운터는 초당 발생하는 쓰레드 전환 개수를 표시한다. 쓰레드의 개수를 증가시키는 것은 성능을 감소시키는 시점까지 컨텍스트 스위치의 개수를 증가시킬 수 있다. 리퀘스트당 10개 혹은 그 이상의 컨텍스트 스위치는 매우 높은 것으로서 만약 이 수치가 나타난다면 쓰레드의 크기를 감소시키는 것이 바람직하다.
커넥션이나 리퀘스트에 의해 측정된 전체적인 성능을 통해 쓰레드의 균형을 잡기란 매우 어려우며 쓰레드를 조정할 때 이에 따른 성능의 증가와 감소 여부를 결정하기 위해 전체적인 성능 모니터링을 병행해야 한다.
만 약 쓰레드 카운트를 적용시키고자 한다면 전체 프로세서 타임에서 프로세스 내의 각각의 쓰레드에 대한 프로세서 타임과 쓰레드의 개수를 비교해 봐야 한다. 만약 쓰레드가 계속 바쁘고 완전하게 프로세서 타임을 사용하고 있지 않다면 쓰레드를 더 많이 생성함으로서 성능을 향상시킬 수 있다. 그렇지만 모든 쓰레드가 바쁘고 프로세서가 자신의 최고 수용력에 가깝다면 개수를 증가시키기 보다는 서버의 개수를 늘여 작업을 분산시키는 것이 바람직하다.

프로세스

① %User Time(임계값 : 사용량 파악)
프로세스의 쓰레드가 사용자 모드에서 코드를 실행하는데 걸린 시간의 백분율이다. 즉 프로세스가 CPU를 사용한 양을 나타내며 이 카운터값을 설정할 때에는 인스턴스를 잘 선택해야 한다. 웹 서버를 운영한다면 인스턴스에서 inetinfo와 dllhost를 선택해 이 프로세스가 얼마나 CPU를 사용하고 있는지 체크해야 한다. 만일 COM+용으로 개발했다면 메모리 운영 방식에서 차이가 있겠지만 dllhost 인스턴스가 두 개 이상이 된다. 모든 dllhost를 관찰하도록 하자.

② Virtual Bytes(임계값 : 사용량 파악)
Virtual Bytes는 프로세스가 사용하고 있는 가상 주소 공간의 바이트 수를 나타낸다. 가상 주소 공간의 사용이 해당 디스크 또는 주 메모리 페이지를 반드시 사용함을 뜻하지는 않는다. 그러나 가상 공간이 한정돼 있으므로 너무 많이 사용하면 프로세스가 라이브러리를 로드하는데 제한받을 수 있다. 메모리 관련 카운터와 조합해서 살펴보도록 해야 한다.
 
③ Thread Count(임계값 : 사용량 파악)
쓰레드란 프로세스안에 실행 가능한 존재를 말한다. 이 카운터값은 프로세스에서 현재 활성화된 쓰레드 수를 나타낸다. 명령은 프로세서에서 기본 실행 단위이고, 쓰레드는 명령을 실행하는 개체다. 모든 실행 프로세스 적어도 하나의 쓰레드를 포함하고 있다. 윈도우 2000에서는 보통 20개 정도가 적당하고 자동적으로 증가한다.

④ Working Set(임계값 : 사용량 파악)
프로세스가 데이터를 저장하기 위해 사용중인 RAM의 양을 나타낸다. 아무런 서비스를 하지 않는데 Working Set의 값이 시간에 지남에 따라 증가하면 프로세스는 메모리 누수 현상을 불러온다. 해당 애플리케이션을 점검해 봐야 한다.

⑤ Private Bytes(임계값 : 사용량 파악)
해당 프로세스에 적용되는 가상 메모리를 기록한다. 즉 해당 프로세스가 사용하는 가상 메모리의 양을 나타낸다. 이 카운터 역시 인스턴스를 잘 선택해야하고 웹 서비스와 관련된 인스턴스를 선택하도록 하자.

⑥ %Processor Time(임계값 : 사용량 파악)
모니터링 대상으로 선택된 프로세스가 시스템에서 사용한 프로세서 시간의 백분율을 나타낸다. 어떤 프로세스가 어느 정도의 CPU 사용률을 기록하는지 파악할 수가 있다.

⑦ Elapased Time(임계값 : 사용량 파악)
프로세스 인스턴스가 수행한 시간(초단위)이 카운터는 오랜 기간 동안의 활동 경향을 추적하는데 유용하며, 또한 What if 시나리오에서 유용하다. 만약 더 많은 애플리케이션 사용자를 추가한다면 CPU 사용량에 어떤 일이 발생할지 볼 수 있다.

⑧ I/O Data Operations/sec(임계값 : 사용량 파악)
프로세스 인스턴스가 생성한 읽기와 쓰기 작업의 수를 나타낸다. 이 카운터는 사용자 생성 I/O 활동에 집중해 What if 시나리오를 분석하고, 애플리케이션 유형들에 대해 I/O 활동량을 추적하는데 유용하다.

⑨ Page Files Bytes(임계값 : 사용량 파악)
Page File Bytes는 이 프로세스가 가상 메모리에 사용한 현재 바이트 수를 나타낸다. 가상 메모리는 다른 파일에 들어있지 않은 프로세스가 사용한 메모리 페이지를 저장하는데 사용된다. 가상 메모리는 모든 프로세스가 공유하므로, 가상 메모리에 공간이 부족하면 다른 프로세스들이 메모리 할당을 할 수 없게 된다. 메모리의 %Committed Bytes In Use와 Committed Bytes와 비교해서 가상 메모리가 부족하지 않은가 판단해야 한다.

⑩ Page Faults/sec(임계값 : 사용량 파악)
메모리 개체에서 전체적으로 페이지 폴트가 일어나는 것을 관찰을 했다면 Process 개체에서는 어떤 프로세스가 그렇게 페이지 폴트를 일으키는지 명확하게 볼 수가 있다. 선택한 인스턴스 중 높은 사용률을 보이는 것을 찾자. 그 프로세스에 해당하는 애플리케이션이 잘못된 것이다.

⑪ Pool Paged Bytes(Instance:Inetinfo) / Pool Nonpaged Bytes(Instance:Inetinfo)
 Pool Paged Bytes(Instance:dllhost#n) / Pool Nonpaged Bytes(Instance:dllhost#n)
위 의 카운터들은 IIS나 Inetinfo 프로세스, 서버내의 인스턴스된 dllhost에 의해 직접 사용되는 풀(Pool) 공간을 모니터하기 위한 것이다. 여기서 주의할 점은 서버 내의 모든 dllhost의 인스턴스에 대한 카운터를 모니터해야 한다는 것이다. 그렇지 않으면 IIS에 의해 사용된 정확한 수치를 얻을 수 없게 된다. 시스템 메모리의 풀은 애플리케이션이나 운영체제에 의해 생성되고 사용되는 객체를 포함하고 있다. 메모리 풀의 컨텐츠들은 오직 우선권이 적용된 모드에서만 접근 가능하다. 즉, 운영체제의 커널만이 직접 메모리 풀을 사용할 수 있다는 의미로 사용자 프로세스는 메모리 풀을 사용할 수 없다. IIS를 구동시키는 서버에는 커넥션을 제공하는 쓰레드는 서비스에 의해 사용되는 다른 객체와 함께 Nonpaged Pool에 저장된다. 메모리의 성능을 향상시키기 위해 무조건 RAM을 증설하는 것보다 다음의 방법을 시도해 보자. 이렇게 해도 메모리와 관련된 성능의 향상이 없다면 RAM을 증설하자.

임계값은 사용량을 파악하는 것이 목적이다.
1. CGI APP를 ISAPI나 ASP로 전환한다.
2. IIS 5.0의 파일 캐시를 재조정한다.
3. 디스크의 속도 향상을 위해 RAID를 고려한다.

※ 이같은 프로세스 값은 전부 애플리케이션과 관계가 있다. 실질적으로 로그를 걸어 놓은 서버는 특별한 애플리케이션이 없이 IIS에 ASP가 실행되는 서버라 해당 카운터값의 inetinfo라는 인스턴스를 체크했다. 특별히 개발해서 운영한다면 그것에 맞춰 보는 것이 바람직하다.

Redirector

① Network Errors/sec(임계값 : 1 이상)
Network Errors/sec는 일반적으로 리디렉터와 하나 이상의 서버에 심각한 통신 문제가 있다는 것을 뜻하는, 예상 밖의 심각한 오류를 나타낸다. 예를 들면, SMB(Server Message Block) 프로토콜 오류가 일으키는 네트워크 에러 등이다. 이는 시스템 이벤트 로그에 항목을 추가하므로 이 파일에서 세부 내용을 참조할 수 있다.

② Server Reconnects(임계값 : 1 이상)
Server Reconnects는 새 활성 요청을 완료하기 위해 리디렉터가 서버에 다시 연결해야 하는 수를 파악한다. 오랫동안 비활성 상태를 유지할 경우, 서버가 연결을 끊을 수 있다. 원격 파일이 로컬로 닫혀 있을 경우에도 리디렉터는 10분 동안(명목상으로) 연결을 그대로 유지한다. 이같은 비활성 상태의 연결을 휴면 연결이라고 하는데, 다시 연결하려면 시간이 많이 소모된다.
 
※ 두 카운터는 파일 서버에서 성능 모니터링을 할 때 필요한 카운터들이다. 참고적으로 알아 본 것이니 웹 서버에서는 그렇게 신경을 안써도 되는 카운터들이다.

서버

① Pool Nonpaged Failure(임계값 : 5 이상)
비페이지 풀에서 할당받지 못한 횟수를 나타낸다. 컴퓨터의 실제 메모리가 너무 작음을 나타낸다.

② Bytes Total/sec(임계값 : 사용량 파악)
서버가 네트워크 데이터를 송수신하는 속도를 보고, 초당 서버 안팎으로 이동하는 총 바이트 수는 서버가 어느 정도 바쁜지를 알 수 있는 좋은 지표가 된다. 서버 로드를 변경하기 위해 어떤 작업을 하는 경우(예를 들면 네트워크에 같은 종류의 서버나 로드 밸런싱을 추가하는 것) 이 값을 모니터링해 변경이 실제로 도움이 되는지 알 수 있다.

③ pool paged Failure(임계값 : 5 이상)
페이지 풀에서 할당받지 못한 횟수를 나타낸다. 컴퓨터의 실제 메모리 또는 페이지 파일이 너무 작음을 나타낸다.

Paging File

① %Usage(임계값 : 90 이상)
현재 사용중인 가상 메모리의 백분율을 나타낸다. 이 값이 90% 이상이 되면 그 원인을 잘 파악해야 한다. 급하면 RAM을 추가해도 된다. 윈도우 서버는 필요하다면 가상 메모리를 더 크게 만들지만 가상 메모리의 크기를 늘리는 것은 권장 사항이 아니므로 RAM 확장을 고려해야 한다.

② %Usage Peak(임계값 : 90 이상)
가상 메모리의 최대 크기를 기록한다. 이 값이 가상 메모리 파일의 최대값에 근접하면 RAM을 더 추가해야 한다. 값이 높으면 가상 메모리가 모든 데이터를 포함할 수 있을 정도로 크지 않다는 것을 의미한다.

Internet Information Services Global

① File Cache Hits%(임계값 : 80% 이상)
이 카운터는 총 캐시 request에 대한 캐시의 히트 비율을 나타내는 것으로 IIS의 파일 캐시의 조정이 잘 작동하는 지를 알 수 있다. 정적인 페이지들로 구성된 웹사이트의 경우 80% 또는 그 이상의 캐시 히트가 일어나야만 좋은 성능을 발휘할 수 있다.

② File Cache Hits
이 카운터는 파일 캐시에 성공한 총 횟수를 나타내며 File Cache Flushes와 로그를 비교해 보면 적절한 비율로 캐시로부터 객체들을 플러쉬 시키는지 알아볼 수 있다.

③ File Cache Flushes
이 카운터는 서버를 시작한 이후로 파일 캐시를 지우는 카운터를 표시하는 것으로 만약 플러쉬가 너무 빠르게 일어난다면 필요 이상으로 객체가 캐시로부터 플러쉬되는 것이고, 반대로 플러쉬가 너무 천천히 일어난다면 메모리의 낭비가 일어난다고 볼 수 있다.

이것으로 윈도우 서버와 IIS에 관련된 성능 카운터는 모든 설정을 한 셈이다. 다음 호에서는 SQL 서버의 성능 카운터를 설정하고, WAS를 실행시키고 성능 모니터의 로그와 SQL 서버의 Profiler와 필요하다면 인덱스 튜닝 마법사를 가지고 분석한 후 사후 용량 계획을 잡도록 하겠다.

작성자 : 이인석 | 프리랜서