본 글에서는 윈도우 시스템의 실제 메모리와 할당된 메모리(가상 메모리/Commit)를 SNMP OID를 통해 불러와 MRTG에서 그래프로 시각화하는 방법을 설명한다. 윈도우 시스템의 메모리 관리가 필요한 이유, 강력한 무료 SNMP 기반 NMS 도구인 MRTG의 소개, 가상 메모리와 물리(실제) 메모리의 차이, 관련 OID의 의미를 살펴보고, 이 값들을 기반으로 메모리 사용률을 계산해 MRTG.CFG에 적용하는 과정을 설명한다.
윈도우 시스템 메모리 관리의 필요성
장시간 가동되는 윈도우 시스템의 메모리 관리는 특히 중요하다. 윈도우가 가동되면서 점차 가용한 메모리 양이 줄기 때문이다. 특히 윈도우 11의 경우, 파일 탐색기의 메모리 누수로 인해 상당히 빠르게 가용 메모리가 줄어 드는 것을 볼 수 있다. 이를 그대로 두고 방치할 경우 시스템이 느려지는 것에서 시작해, 결국 시스템이 다운되는 상황을 맞이하게 된다.
가장 좋은 해결방법은, 정기적으로 시스템을 재부팅하는 것이다. 이것만으로도 대부분의 문제는 해결된다. 하지만, 재부팅 주기가 다가오기 전에 문제가 발생할 수도 있다. 어떤 경우에는 시스템의 재부팅 작업 자체를 실행하기 어려운 개떡같은 경우도 있다. 또한, 적절한 재부팅 주기를 찾기 위해서는 평소에 시스템 메모리가 어떻게 사용되고 있는지 알고 있어야 할 필요가 있다.
NMS와 MRTG
NMS(Network Management System)는 네트워크 장비들의 상태를 감시하고 보여주는 시스템을 가리키는 말 이었다. 그리고 의미와 쓰임이 확장되어, 네트워크장비와 네트워크를 구성하는 서버시스템, 더 나아가 종류와 산업의 구분을 떠나, 어떤 서비스의 상태를 감시하고 파악하는 관제 시스템을 폭넓게 부르는 말이 되었다.
그 중에서도 MRTG(Multi Router Traffic Grapher)는, 매우 오랜 기간동안 사용되어온 NMS 도구이다. 주로 네트워크 라우터나 스위치의 포트에 대한 트래픽을 모니터링하고 시각화 하는 용도로 사용되나, 그래프를 통한 시각화가 가능하다는 특징으로 트래픽뿐 아니라 여러 가지 서비스의 상태를 보여주는 도구로 지금까지 사용되고 있다.
물론 시간이 흐름에 따라 MRTG의 역할을 대체할 수 있는 많은 도구들이 소개 되었으나, MRTG처럼 레퍼런스가 쌓여있고 무엇보다 무료인 도구는 찾아보기 쉽지 않다.
SNMP와 OID
PC를 포함한 네트워크를 구성하는 많은 장치들은 NMS와 연동을 위한 기본적인 기능을 가지고 있는데, 이때 사용되는 통신 규약이 SNMP(Simple Network Management Protocol)이라고 하는 프로토콜이다.
에이전트(SNMP에서 모니터할 대상 시스템)는 자신이 제공할 수 있는 데이터들의 항목에 각각의 OID(Object ID)를 지정해 놓는다. 매니저(SNMP에서 NMS 서버 역할을 하는 시스템)가 특정한 OID에 대한 정보를 요청하면, 에이전트는 해당 OID에 대한 값을 응답으로 보내주게 된다. 이것이 기본적인 SNMP 기반의 NMS시스템의 동작 구조이다.
윈도우 시스템의 메모리와 OID
윈도우 시스템 역시 자신이 제공할 수 있는 각종 데이터들에 OID값을 할당해 두었다. 우리가 사용해야 할 OID를 정확히 특정하기 위해서는 어떤 데이터를 읽어와야 하는지 알고 있어야 한다.
윈도우 시스템의 두 가지 메모리

윈도우 시스템의 메모리는 실제 메모리(Physical Memory)와 할당된 메모리(Commit Charge)의 두 개념이 존재한다. 각각의 의미를 간단히 정리하자면,
- 실제 메모리
- 시스템에 장착되어 있는 물리적인 하드웨어 메모리로, 흔히 말하는 ‘램이 몇 기가에요’ 할 때의 메모리를 의미한다.
- 할당된 메모리
- 윈도우 커널이 사용할 수 있는 메모리의 양으로, 실제 메모리와 페이지파일의 크기를 합친 것을 말한다. 가상 메모리라고도 불리며, 윈도우 시스템이 확보해 두고 사용하는 논리적 메모리이다. 메모리 부족 여부의 기준이 된다.
상황과 관리자의 성향에 따라 선택할 수 있겠으나, 윈도우 시스템의 메모리 관리를 위해서는 보통 이 두 가지를 모니터하게 되며, 둘 중에서 하나만 선택한다고 하면 할당된 메모리(커밋 차지)를 선택하는 것이 일반적이다. (상세한 이유는 이 글에서 다루지 않겠다.)
윈도우 시스템의 메모리를 관리하기 위해 어떤 팩터를 모니터해야 하는지 알았으니, 실제로 OID 값을 찾아 사용하는 방법을 알아보도록 하겠다. (이 부분을 읽기 전에 SNMP OID의 구조에 대한 글을 먼저 읽어보기를 권한다.)
윈도우 시스템의 메모리 OID 확인
윈도우 시스템의 SNMP서비스에서 메모리는 장비의 저장소(Storage) 중 하나로 분류되며, 저장소와 관련된 OID는 1.3.6.1.2.1.25.2.3.1 아래에 위치하고 있다. 해당 OID를 SNMPWALK로 확인해 보면 다음과 비슷한 목록이 나올 것이다.
| Name/OID | Value | Type |
|---|---|---|
| 1.3.6.1.2.1.25.2.3.1.1.1 | 1 | Integer |
| 1.3.6.1.2.1.25.2.3.1.1.2 | 2 | Integer |
| 1.3.6.1.2.1.25.2.3.1.1.3 | 3 | Integer |
| 1.3.6.1.2.1.25.2.3.1.1.4 | 4 | Integer |
| 1.3.6.1.2.1.25.2.3.1.2.1 | 1.3.6.1.2.1.25.2.1.4 | OID |
| 1.3.6.1.2.1.25.2.3.1.2.2 | 1.3.6.1.2.1.25.2.1.7 | OID |
| 1.3.6.1.2.1.25.2.3.1.2.3 | 1.3.6.1.2.1.25.2.1.3 | OID |
| 1.3.6.1.2.1.25.2.3.1.2.4 | 1.3.6.1.2.1.25.2.1.2 | OID |
| 1.3.6.1.2.1.25.2.3.1.3.1 | C:\ | OctetString |
| 1.3.6.1.2.1.25.2.3.1.3.2 | Z:\ | OctetString |
| 1.3.6.1.2.1.25.2.3.1.3.3 | Virtual Memory | OctetString |
| 1.3.6.1.2.1.25.2.3.1.3.4 | Physical Memory | OctetString |
| 1.3.6.1.2.1.25.2.3.1.4.1 | 4096 | Integer |
| 1.3.6.1.2.1.25.2.3.1.4.2 | 0 | Integer |
| 1.3.6.1.2.1.25.2.3.1.4.3 | 65536 | Integer |
| 1.3.6.1.2.1.25.2.3.1.4.4 | 65536 | Integer |
| 1.3.6.1.2.1.25.2.3.1.5.1 | 55528047 | Integer |
| 1.3.6.1.2.1.25.2.3.1.5.2 | 0 | Integer |
| 1.3.6.1.2.1.25.2.3.1.5.3 | 299700 | Integer |
| 1.3.6.1.2.1.25.2.3.1.5.4 | 260788 | Integer |
| 1.3.6.1.2.1.25.2.3.1.6.1 | 11428996 | Integer |
| 1.3.6.1.2.1.25.2.3.1.6.2 | 0 | Integer |
| 1.3.6.1.2.1.25.2.3.1.6.3 | 107504 | Integer |
| 1.3.6.1.2.1.25.2.3.1.6.4 | 109841 | Integer |
1.3.6.1.2.1.25.2.3.1.1.X(적색)- SNMP에서 저장소로 인식한 장치들에 대한 인덱스 번호이다. 뒤에 이어지는 OID들의 X 부분에는 여기서 표시된 인덱스 번호를 적용하면 된다. 예의 그림에서는 1부터 4까지 총 4개의 저장소가 있음을 알 수 있다.
1.3.6.1.2.1.25.2.3.1.3.X(등색)- 저장소 설명(Storage Description) 영역으로, 저장소의 타입과 인스턴스를 표기하는 OID이다. 인덱스 번호 1은 C드라이브, 2는 Z드라이브, 3은 가상 메모리, 4는 실제 메모리로, 우리가 관심을 가질 인덱스는 3, 4임을 알 수 있다.
1.3.6.1.2.1.25.2.3.1.4.X(황색)- 저장소 할당 단위(Storage Allocation Units) 영역이다. 인덱스 번호 1은 C드라이브로, 4096Byte 단위로 할당됨을 알 수 있다. 메모리의 경우 65536Byte가 기본 할당 단위이다. 이 숫자는 저장소의 실제 크기를 계산하는 데 필요하다.
1.3.6.1.2.1.25.2.3.1.5.X(녹색)- 저장소 크기(Storage Size) 영역이다. 해당 저장소의 전체 크기가 몇 단위(Unit)인가 나타낸다.
1.3.6.1.2.1.25.2.3.1.6.X(청색)- 저장소 사용량(Storage Used) 영역이다. 해당 저장소의 현재 사용량이 몇 단위(Unit)인가 나타낸다.
예를 들어 C드라이브의 전체 용량과 사용 중인 용량을 알고 싶다면 이렇게 계산할 수 있겠다.
OID의 스토리지 인덱스에서 알 수 있듯이, 메모리의 인덱스 번호는 리스트 마지막에 위치한 경우가 많다. 이 말은, 만약 시스템에 다른 저장소가 더 있을 경우(하드가 더 달려 있는 경우) 인덱스 번호가 뒤로 밀릴 수 있다는 말이다. 때문에 메모리의 인덱스 번호가 몇 번인지 OID value를 보고 잘 선택해야 한다.
메모리 사용률 계산
최종적으로, 이 게시물의 예에서 윈도우 시스템의 실제 메모리와 할당된 메모리의 사용 백분률은 이렇게 표시될 수 있다.
만약 백분율이 아니라 실제 용량을 계산하고자 한다면 위에서 본 C드라이브의 용량 계산과 같이 할당단위를 곱해주면 실제 용량을 계산할 수 있다.
MRTG.CFG 적용
이제 마지막 단계로 MRTG.CFG파일에 실제 메모리 사용률과 할당된 메모리 사용률을 표시하기 위해 타겟 정보를 입력해 주면 된다. MRTG는 OID 값에 대한 산술계산이 가능하다. Target부분을 주의 깊게 보기 바란다.
Target[SVR_RAM]: 1.3.6.1.2.1.25.2.3.1.6.3&1.3.6.1.2.1.25.2.3.1.6.4:public@192.168.123.123:::::2 / 1.3.6.1.2.1.25.2.3.1.5.3&1.3.6.1.2.1.25.2.3.1.5.4:public@192.168.123.123:::::2 * 100
MaxBytes[SVR_RAM]: 100
SetEnv[SVR_RAM]: MRTG_INT_IP="No Ip" MRTG_INT_DESCR="VMEM"
Unscaled[SVR_RAM] : yd yw ym yy
Title[SVR_RAM]: SVR Memory Usage
YLegend[SVR_RAM] : Percent
LegendI[SVR_RAM] : VMEM Usage
LegendO[SVR_RAM] : PMEM Usage
Legend1[SVR_RAM] : Virtual Memory Usage
Legend2[SVR_RAM] : Physical Memory Usage
ShortLegend[SVR_RAM] : %
...(생략)...
1.3.6.1.2.1.25.2.3.1.5.3- 전체 가상 메모리(Unit) 값이다. hrStorageSize에 해당하며, 인덱스 3은 가상 메모리를 뜻한다.
1.3.6.1.2.1.25.2.3.1.6.3- 사용 중인 가상 메모리(Unit) 값이다. hrStorageUsed에 해당한다.
1.3.6.1.2.1.25.2.3.1.5.4- 전체 물리 메모리(Unit) 값이다. 인덱스 4는 실제 메모리를 뜻한다.
1.3.6.1.2.1.25.2.3.1.6.4- 사용 중인 물리 메모리(Unit) 값이다.
&- MRTG에서 입력(IN)과 출력(OUT)을 구분하는 연산자이다. 앞(OID)은 IN, 뒤(OID)는 OUT에 매핑된다.
public@192.168.123.123:::::2- 타겟 호스트의 IP 주소와 커뮤니티 이름
* 100- 백분율로 나타내기 위해 100을 곱해준다.
즉, 입력 그래프에는 사용중인 가상 메모리를 전체 가상 메모리로 나눈 값을 표시해 주고, 출력 그래프에는 사용중인 물리적 메모리를 전체 물리적 메모리로 나눈 값을 표시해 주는 설정이다. 정상적으로 진행되었다면 아래의 그래프와 같이 윈도우 시스템의 메모리 사용률을 MRTG를 통해 모니터할 수 있게 된다.

마무리
NMS 시스템은 구축해 놓고 끝이 아니다. 평소에 잘 눈에 익혀 두어야 무언가 문제가 생겼을 때 바로 알아차리고 필요한 조치를 취할 수 있다.
SNMP와 MRTG를 이용한 메모리 모니터링은 별도의 비용 없이도 안정적인 시스템 관리 환경을 구축할 수 있는 현실적인 방법이며, 특히 장시간 무중단으로 운영되는 윈도우 서버나 클라이언트 시스템에 매우 유용하다.
서버 관리 때문에 골치 썩고 있는 독자 제위께 본 글이 작은 도움이 되기를 바라는 바이다.