vmstat을 활용한 시스템 리소스 모니터링

개요

vmstat은 리눅스에서 가장 기본적인 시스템 모니터링 명령어이자, 시스템 리소스 이상 유무를 판단할 수 있는 중요한 명령어이다. 간단한 명령어를 이용하여 손쉽게 시스템의 상태를 진단할 수 있어 성능테스트와 같은 특정 목적을 위해 사용하기도 하지만, 일상 모니터링 용도로도 vmstat은 많이 사용된다.

---

vmstat 명령어 예시

a. vmstat : default 실행

[root@ip-192-168-114-198 ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 504328   2088 342004    0    0  9076   243  512 3103 36 10 26  1 26
[root@ip-192-168-114-198 ~]# 

b. vmstat [repeat_time] : 반복 시간 설정 후 실행

[root@ip-192-168-114-198 ~]# vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 503440   2088 342264    0    0  3437   137  238 1284 14  4 72  0 10
 0  0      0 503440   2088 342264    0    0     0     0   65  158  0  0 100  0  0
 0  0      0 503440   2088 342264    0    0     0    69   69  166  0  0 100  0  0
 0  0      0 502804   2088 342464    0    0    35     0   70  234  0  0 99  0  0
 0  0      0 502836   2088 342464    0    0     0    89   85  161  0  0 100  0  0

c. vmstat [repeat_time] [repeat_count] : 몇초에 한번씩 몇번 반복 후 종료

[root@ip-192-168-114-198 ~]# vmstat 3 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 502932   2088 342464    0    0  1818    78  158  758  7  2 85  0  5
 0  0      0 502932   2088 342464    0    0     0     0   69  167  0  0 100  0  0
 0  0      0 502932   2088 342464    0    0     0     0   64  156  0  0 100  0  0
 0  0      0 502932   2088 342464    0    0     0     0   65  161  0  0 100  0  0
 0  0      0 502932   2088 342464    0    0     0    24   65  162  0  0 100  0  0
[root@ip-192-168-114-198 ~]# 

---

vmstat 명령어 보는 법

다음 결과를 기반으로 아래와 같은 정보들을 모니터링 해 보도록 하자.

[root@ip-192-168-114-198 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 502096   2088 342756    0    0   543    25   87  326  2  1 95  0  2
 0  0      0 502096   2088 342756    0    0     0     0   57  129  0  0 100  0  0
 0  0      0 502096   2088 342756    0    0     0     0   50  119  0  0 100  0  0
 0  0      0 502096   2088 342756    0    0     0     0   49  122  0  0 100  0  0
 0  0      0 502096   2088 342756    0    0     0     0   62  151  1  0 99  0  0
 0  0      0 502096   2088 342756    0    0     0     0   54  135  0  0 100  0  0
 0  0      0 502096   2088 342756    0    0     0     0   48  113  0  0 100  0  0
 0  0      0 502096   2088 342756    0    0     0     0   50  115  0  0 100  0  0

Average (명령어 실행 후 첫번째 결과 값)

vmstsat을 수행하면 위와 같이 첫번째 결과는 다른 결과와 다르게 수치가 많이 차이나는 것을 볼 수 있다. 이는 vmstat의 명령어를 수행한 후 항상 첫번째 줄은 이전의 vmstat 명령어로 수집된 정도에 대한 평균치를 나타내기 때문이다. 즉 현재의 정보가 아닌 이전에 누적된 정보임을 기억해야 한다.

vmstat 명령의 첫번째 줄은 평균치를 나타내기 때문에 실제 의미가 없는 데이터라고 생각하고 모니터링을 수행한다. 주의할 점은 vmstat으로 script 등을 작성하여 시스템의 평균치 등을 모니터링할 경우 항상 첫번째 줄은 제외하고 통계치를 계산하도록 해야 한다.

Queue (procs)

procs 항목은 os 별로 다른 항목으로 존재하기도 하지만, 그 의미는 동일하다고 볼 수 있다. 현재 CPU내에 존재하는 Queue에 적체된 Command의 수를 의미한다.

r (run queue) : 작업 수행을 위해 CPU 자원을 기다리는 Command 수

b (blocked queue) : 메모리나 기타 I/O 등에 대해 대한 자원을 기다리는 Command 수

CPU의 Queue에 대한 현재 상태를 보여주는 것으로 모니터링시에 r(run queue)항목이 중요하다. r 항목의 단위는 건수라고 보면 되고 이 개수가 많으면 많을 수도록 OS 자체의 Bottleneck이 존재함을 의미한다.

Memory (memory)

memory 항목에서 주요한 것은 free항목으로 free는 해당 OS의 실제 남은 메모리를 의미한다.

Linux의 경우 Free 사이즈가 곧 남은 KiB 사이즈로 볼 수 있다. Unix에서는 Free의 단위가 List로 해당 OS의 페이지 개수이다. (free list라는 말중에 list는 실제 해당 free 메모리를 관리하는 자료구조가 list이기 때문) 페이지는 일반적으로 메모리의 최소 단위를 의미하는 것으로 전통적인 Unix에서는 4KB크기이다. 즉 만약 free에 위와 같이 14532라는 숫자가 있다면, free 메모리 = 14532 x 4KB = 56MB정도의 여유메모리가 존재한다.

free의 수가 현저히 적다면 실제 OS의 물리적인 메모리가 부족하다고 판단하여도 큰 무리가 없다. 그럼 실제로 해당 숫자가 적으면 무조건 OS메모리가 부족한 것인지 고민해 봐야 한다.
OS에 따라 다르지만 일반적으로는 물리 메모리가 적을 가능성이 크다고 판단하는 것이 합리적이나 OS에 따라서 File Cache로 사용된 메모리 또한 free-list에서 빠지는 경우도 있다. 즉 File에 대한 Cache가 우선순위가 낮아 메모리가 여유가 있을 경우에는 File Cache로 많이 사용하고 있다가 실제 물리적인 메모리가 부족하면 자동으로 File-Cache영역을 줄여 물리적인 메모리의 크기를 증가시키는 경우도 있다. (주로 IBM AIX의 경우)

System Call (system)

system 항목은 시스템 콜 및 인터럽트에 관련된 정보를 보여준다.

sy (system call) : OS의 시스템영역에서 수행하는 시스템 콜 개수

cs (context switch) : CPU내에서 Process간 Context정보를 교체하는 회수이다.

cs는 CPU 및 메모리에서 수행되는 Process들의 고유한 정보를 context라고 표현할 수 있으며, sy는 OS에서 사용자의 작업수행 영역이 아닌 OS의 자원을 이용해야 할 필요성이 있는 작업, 파일에 데이터를 기록 한다던지, Socket에 데이터를 전송한다던지 하는 OS적인 작업을 수행할때 호출되는 함수이다.

cs는 CPU자원에 대한 Process들의 경쟁이라고 생각하면 될 것으로 보이며, 또한 cs와 sy의 경우 또한 절대적인 값이라기 보다는 모니터링시의 상대적인 값으로 판단하는 것이 옳다. 즉 이전일보다 cs나 sy의 숫자가 상당히 크다면, 이전일보다 CPU에 대한 Process간 경쟁이 치열하다고 판단할 수 있다. 이러한 경우는 자연스럽게 CPU사용률이 높은 경우라고 판단할 수 있다.

sy의 경우도 마찬가지로 상대적인 숫자값으로 판단할 수 있으며, 이전일보다 sy숫자가 현격히 높다면 OS가 이전보다 사용자의 작업보다는 OS적인 작업을 더 많이 수행한다고 할 수 있다.

[중요] 일반적으로 이 두가지 항목은 상대적으로 OS의 Bottleneck을 판단하는데 명확한 데이터는 아니며, 상당히 미묘한 문제가 발생되었을 경우 좀 더 나은 판단을 위해 알고 있어야 할 사항이다.

CPU (cpu)

cpu 항목은 CPU사용률를 나타낸다. 이 항목은 엔지니어들이 가장 많이 보는 항목으로 익숙한 내용이며, CPU사용률에 대한 정보이다.

us (user CPU) : 사용자 영역에서 사용하는 CPU 비율

sy (system CPU) : 시스템 콜에 호출에 의해 사용되는 CPU 비율

id (idle CPU ) : 사용가능한 CPU 비율 (일반적으로 100 – (us + sy) = id

wa (wait I/O) : disk 혹은 기타 I/O작업으로 인해 대기하는 CPU

[중요] 항상 고객사에서 CPU 점유율이 높다고 고객이 언급할 경우 필수적으로 해당 CPU가 us인지 sy인지 확인해야 한다. us와 sy를 확인하는 가장 큰 이유는 어느 CPU가 높으냐에 따라서 원인분석을 위한 명령어가 달라지기 때문이다.

us가 높을경우 일반적으로 OS명령어를 통해 바로 알 수 있는 경우는 많지 않으며, java인 경우에는 kill -3과 ti명령을 통해 대략적으로 확인할 수 있는 가능성이 높다.

sy가 높은 경우는 java/c 할거 없이 truss명령을 통해 어떠한 시스템 콜이 수행중인지 확인이 가능하다.

---

결론

시스템을 모니터링할 때 단순히 서비스가 느리다라고 표현하는 엔지니어들이 많이 있다. 이러한 문제의 원인은 다양하고 접근하는 방법이나 절차도 다양하다.

첫 로그인 후 vmstat을 통해 해당 시스템의 정상유무나 이상여부를 판단해 보는 것도 문제 해결을 조금 앞당기는 방안이라고 생각한다.

위의 vmstat는 기본적인 공통 명령어이므로, 실제 자세한 파악을 위해서는 다양한 모니터링 툴들이 있습니다.

IBM : topas, nmon / HP : glance, glance plus / Sun : prstat 정도의 명령어에 대해서는 추가적으로 알아 두는 게 좋다.

모니터링 결과 CPU를 많이 사용하고 있을 경우 엔지니어는 "User입니까 CPU입니까"라는 정도의 질문은 기본적인사항이다. vmstat을 활용할 줄 안다면, 모든 OS의 기본정보를 획득하는 것은 매운 쉬운일이다.

OS나 WAS/WEB 또는 IT에 종사하는 일반적인 엔지니어들은 vmstat 이라는 명령어를 최소 1번 이상 다루어 보았거나 들어보았을거라고 생각한다. 명령어가 쉽고 간단하고 Summary를 제공하기 때문에 어렵지 않게 사용하곤 하지만 이를 통해서도 복잡한 Bottleneck을 조기에 진단하고 원인 규명을 할 수 있다는 것에 의미를 두고 싶다.