부하율측정

제 목 : 유닉스 시스템 관리자(마지막회)
유닉스 시스템관리자(마지막회)
시스템 튜닝

양종윤 : 인하 대학교 전자계산공학과 전문가시스템 연구실
하이텔-huclons 천리안-huclons

이번 호에는 시스템 튜닝에 대해 설명하도록 하겠다.

들어가며
대부분의 유닉스 초심자들은 시스템의 여러 가지 세팅을 적절히 조절해 주면
시스템의 성능이 매우 크게 향상될 것이라는 생각을 가지곤 한다. 하지만 이는
커다란 착각(?)이라고 말해주고 싶다. 왜냐하면 이미 왠만한 상업용 유닉스 시
스템들은 어느 정도의 최적화가 된 상태로 시장에 나오는 것이기에 정확한 지
식 없는 시스템 튜닝은 오히려 부작용을 일으킬 수 있는 것이다. 물론 리눅스
나 FreeBSD와 같은 비상업용 유닉스를 쓰는 경우는 논외로 하겠다. 그러므로
유닉스 시스템 성능 향상을 위한 튜닝의 기본적인 원칙은 다음과 같다.

시스템이나 네트워크에 너무 많은 부하가 걸리지 않도록 한다. 부하가 많이
걸리게 되면 자원을 기다리는 프로세스들이 많아지게 되고 그러면 점점 누적되
어 시스템의 성능이 급격히 저하되기 때문이다.
불필요한 기능이나 쓸모없는 일을 위해 시스템 여분의 성능을 낭비하지 않
는다. 예를 들면 시스템의 쿼터(용량제한)나 CPU 사용계산(Accounting) 등이
별로 필요 없는 경우 이에 대한 시스템의 불필요한 사용은 시스템의 성능저하
의 한 몫만을 할뿐이다.

추가적으로 고려할 사항은 프로그램을 만들 때는 시스템 성능을 고려한 프로그
램의 작성이 요구되며 필요한 시스템 작업이 요구되는 경우 부하가 적은 야간
을 이용해 cron을 돌려놓으면 좋다.
성능 향상을 위한 일반론

다음은 시스템의 성능을 향상시키기 위해서 필요한 것들이다. 이것은 유닉스





시스템뿐만 아니라 다른 운영체계의 시스템에도 해당되는 것이다.

시스템이 충분한 메모리 크기를 가지도록 하자. 일반적으로 운영체계에서
요구하는 기본 메모리 양이 있다. 이를 충분히 수용할 수 있어야만 그 시스템
은 기대되는 성능을 낼 수 있는 것이다.
프로그램의 잘못된 사용을 바로잡는다. 앞서도 언급하였지만 시스템의 성능
을 고려하지 않고 프로그램을 짜서 수행시키는 경우나 한꺼번에 많은 프로그램
들을 불필요하게 수행시키는 등의 일은 시스템의 성능을 떨어뜨리는 결과를 초
래한다. 또한 불필요한 데몬의 수행도 마찬가지의 결과를 가져오는 것이다.
시스템의 하드 디스크나 파일 시스템을 정리한다. 이는 파일 시스템의 여러
가지 옵션을 조정하는 것과 쓸모 없는 디렉터리나 파일의 정리도 포함된다.
항상 네트워크 상태를 모니터링 한다. 특히 에러율이 낮은지를 netstat 명령
을 통해 체크한다.
커널 재조정을 통해 필요없는 드라이버와 옵션 등을 제거한다. 예를 들면
자신의 시스템에 장착되어 있는 하드웨어를 제외한 다른 회사의 드라이버들은
제거해도 아무 지장이 없다. 다만 만일의 경우를 고려해 기존의 드라이버들이
모두 있는 커널의 백업은 받은 후에 제거한다.

시스템 성능에 영향을 주는 요소들
시스템 성능에 영향을 주는 요소들은 다양하게 존재한다. 이 요소들은 여러 가
지로 파악될 수 있지만 그 중에서도 시스템의 프로그램들이 사용하는 리소스의
측면에서 파악하는 것이 일반적이다. 시스템의 성능에 영향을 주는 요소들을
리소스 측면에서 파악하면 다음과 같다.
(1) CPU 사용 시간
(2) 메모리
(3) 하드 디스크 I/O 양
(4) 네트워크 I/O 양

모든 프로세스는 시스템 리소스의 일부를 사용한다. 이러한 리소스들을 여유있
게 프로세스들이 사용한다면 시스템의 성능은 양호한 것이다. 하지만 그렇지
않고 리소스가 없어 프로세스들이 기다리는 경우가 늘어날수록 그 시스템의 성
능은 감소되는 것이다. 프로세스들이 기다리는 시간을 시스템 성능의 척도로
사용하는 경우도 이러한 이유 때문이다. 리소스 측정에 대하여 이제부터 설명
하도록 하겠다. 참고로 메모리에 대해서 간단히 설명하자면 유닉스 시스템에서
는 가상 메모리를 사용한다. 요즘은 다른 운영체계에서도 기본으로 되었지만
이것이 모두 유닉스의 가상 메모리 개념을 가져다 변형한 것으로 보아도 무방
하다. 이러한 가상 메모리는 실제 메모리의 부족을 하드 디스크를 통해 보완하
는 개념이다. 사용하지 않는 하드 디스크 저장 공간을 메모리처럼 사용하는 것
이다. 여기에는 한계가 발생하게 된다. 만약 시스템에서 사용하려는 메모리 공
간이 실제 메모리에 있지 않고 하드 디스크에 있는 경우 하드 디스크의 내용을
읽어 메모리로 적재하고 기존의 메모리 공간은 하드 디스크로 옮기는 것이 필
수적이다. 이 과정을 페이징(Paging)이라 한다. 페이징이 일어나는 메모리 블록
을 일반적으로 페이지(Page)라고 한다. 페이지는 보통 4K이상으로 구성되며 이
는 일반적인 디스크 입출력 단위인 디스크 블록(1K 혹은 512byte)이 여러 개
모인 것이다. 하드 디스크에 있던 메모리 페이지가 메모리로 적재되는 것을 페
이지 인(Page In)이라 하고 메모리에 적재되어 있던 것을 페이지 아웃(Page
Out)이라 한다. 이 페이징의 과정이 많이 일어날수록 시스템의 성능은 감소한
다. 하드 디스크의 접근 속도가 메모리의 접근 속도에 비해 떨어지는 것은 당
연하기 때문이다. 같은 시스템 환경에서 페이징을 줄이기 위한 노력도 많이 이
루어졌는데 그 중의 하나가 지역성(locality)과 캐시이다. 캐시나 지역성 모두
가능하면 페이징을 줄이도록 페이징이 가장 적게 일어날 확률을 가진 페이지들
을 메모리에 유지하는 것을 목표로 한다. 가상 메모리에 대한 자세한 내용은
전산학의 운영체계에 관련된 도서를 참고하기 바란다.

프로그램의 시간 체크하기
프로그램의 시간을 측정해야 하는 경우가 발생한다. 이러한 경우 ‘/bin/time’
명령어를 사용한다. 주의할 점은 C 셸에 내장되어 있는 time 명령과는 다르다
는 점이다. 그러므로 사용할 때는 디렉터리도 함께 명시한다. 다음은 그 사용예
이다.

% /bin/time vmstat
procs memory page disk faults
cpu
r b w avm fre re at pi po fr de sr d0 d1 d2 d3 in sy cs us sy id
1 0 0 0 7584 0 3 0 0 0 0 0 1 0 0 0 14 4 2 0 0 99
0.6 real 0.5 user 0.1 sys

위에서 보면 전체 0.6초가 걸렸고 그 중 0.5초는 사용자 코드이며 0.1초가 시스
템 호출 등의 커널 관련 경과 시간을 나타낸다. 자신이 만든 프로그램이 얼마
나 시스템 콜 등의 커널관련 작업을 수행하는지 파악하고자 할 때 매우 유용한
명령인 것이다.

시스템의 성능 측정하기
시스템의 성능을 측정하는 데는 일반적으로 ATT 계열이 BSD 계열보다 모니
터링 도구가 좋은 평가를 받는다. 실제로 ATT 계열은 sar 명령어를 이용하면
모든 요소를 측정할 수 있지만 BSD 시스템의 경우는 각 요소마다 다른 명령
어를 사용해야 하므로 일단 ATT 계열의 사용이 편리(?)하다는 생각이 든다.

현재 CPU 성능 측정
CPU의 성능을 측정하기 위해서는 다음의 3가지를 체크해야 한다.
(1) 전체 사용정도
(2) 평균 부하
(3) 프로세스별 CPU 사용정도

이러한 모든 정보는 ATT 계열의 경우는 ‘sar -u’ 명령을 사용하여 알아내
며 BSD 계열의 경우는 vmstat 명령을 이용한다. 하지만 필자가 여러 시스템을
테스트해 본 결과 많은 ATT계열의 시스템들이 vmstat 명령을 지원하는 것으
로 나타났다. 독자들은 어찌되었건 두 가지 명령어 모두 알아두도록 하자. 두
명령어 모두 2개의 인자를 가지는데 하나는 ‘측정 시간 간격’이고 다른 하나
는 ‘통계를 낼 횟수’ 즉 몇번 측정하고 통계 기록을 보여줄지를 지정하는 것
이다.
다음은 ATT 계열의 사용예이다.
% sar -u 5 5
23:12:30 %usr %sys %wio %idle
23:12:35 4 58 27 11
23:12:45 7 83 9 0
23:12:50 6 76 6 0
23:12:55 4 73 8 0
23:13:00 4 85 4 0

‘%usr’는 사용자 코드를 수행하는데 사용되는 CPU 시간의 백분율이며
‘%sys’는 시스템 커널의 코드를 수행하는데 사용되는 CPU 시간의 백분율
이다. 그리고 ‘%wio’와 ‘%idle’은 CPU의 Idle 시간을 나타내는 백분율인
데 원인이 디스크 I/O때문이면 ‘%wio’에 나타나고 그 외의 이유라면
‘%idle’에 속하게 된다. 위의 시스템의 경우 많은 부분을 커널이 사용하고
있는데 이는 어찌 보면 당연한 결과이다. 우리가 주목해야 할 부분은 Idle 비율
로 위의 경우는 CPU가 리소스를 기다리는 시간이 얼마 안되므로 시스템에는
큰 부하 없이 잘 돌아감을 의미한다.
‘vmstat’ 명령도 여러 정보를 제공해 주는데 다음은 그 사용 예이다.

% vmstat 5 5
procs page faults cpu
r b w re mf pi po fr de sr in sy cs us sy id
0 0 0 0 0 0 0 0 0 0 4 22 19 2 1 97
1 0 0 67 2 0 0 0 0 0 26 751 52 53 47 0
0 0 0 96 0 0 0 0 0 0 39 1330 42 22 71 7
0 0 0 16 0 0 0 0 0 0 84 1626 99 7 74 19
0 0 0 1 0 0 0 0 0 0 11 216 20 1 11 88

‘sar -u’ 명령에 나왔던 항목들이 여기서는 cpu 필드의 us, sy, id 열에 나
타난다. 위 시스템의 경우는 시스템의 Idle time이 부분적으로 높게 나타나므로
현재 부하가 어느 정도 걸리고 있음을 알 수 있다. 수치가 일정치 않음은 여러
요인에 의한 것이므로 좀 더 오랫동안 모니터링 하여 확인해야 할 것이다. 다
음 표는 두 명령에서의 항목을 비교해 나타내었다.

sar명령 vmstat명령 설명
(u 옵션) (cpu 항목)
%usr us 사용자 코드를 수행하는 CPU 시간에 대한 백분율
%sys sy 시스템 커널 코드를 수행하는 CPU 시간에 대한 백
분율
%wio id 디스크 I/O에 의해 CPU가 기다리는 시간(idle time)
에 대한 백분율
%idle 디스크 I/O 이외의 이유로 인해 CPU가 기다리는 시
간에 대한 백분율

부가적으로 fault 필드의 in은 초당 디바이스 인터럽트 횟수, sy 항목은 초당
시스템콜의 횟수를 나타내며 cs 항목은 일정 시간동안(보통 초당)의 context
switching, 즉 프로세스의 제어권의 변경 횟수를 나타낸다. 다른 항목은 조금
후에 알아보도록 하겠다.

vmstat명령(fault항목) 설명
in 초당 디바이스 인터럽트 횟수
sy 초당 시스템콜 수
cs 초당 컨텍스트 스위칭(context switching) 회수

참고로 솔라리스의 경우는 위의 sar와 vmstat 명령을 모두 제공한다.
사실, CPU의 상태는 순간순간 급격히 변하기 때문에 짧은 시간동안의 모니터
링은 그다지 정확한 정보를 나타내지 않는다. 그러므로 되도록 오랜 시간동안
모니터링을 하여야 정확한 정보를 알 수 있다.

평균 부하(load average)
또하나의 유용한 CPU 통계정보로 평균 부하가 있다. 일반적으로 평균 부하는
디스크나 I/O의 대기 시간도 포함하므로 순수한 CPU 사용에 대한 척도를 나
타내는 것은 아니다. 하지만 CPU가 얼마나 골고루 사용되는지를 나타내는 좋
은 척도임은 사실이다. 실제로 이 평균 부하 수치는 일정 시간동안 수행 대기
큐에서 기다리는 작업의 수에 대한 평균을 내는 것이다.
평균 부하는 uptime 명령을 통해 얻을 수 있다.

% uptime
2:07pm up 4:02, 5 users, load average: 0.95, 0.38, 0.31

위에서 보면 3가지 수치가 나오는데 이는 각각 5분, 10분, 15분의 평균을 나타
낸 것이다. 이 시스템의 경우는 평균적으로 대기중인 작업이 1개가 채 안되므
로 부하가 별로 없음을 의미한다. 이 수치가 5이상 되면 어느 정도 부하가 걸
리고 있다고 생각하면 무방할 것이다. 하지만 이런 경우 디스크 I/O 위주의 프
로그램이 많아서 수치가 높게 나타나는 경우도 있으므로 vmstat나 sar 명령으
로 다시 한번 확인해 보기 바란다.

페이징 알고리듬
유닉스 시스템에서는 가상 메모리에 대한 페이징을 수행한다고 하였다. 이를
위해서는 시스템이 어떠한 페이지를 교체, 스왑핑(swapping)할 것인가를 결정
하여야 한다. 일반적으로 가장 최근에 사용하지 않은 페이지를 선택해 교체하
는 LRU(Least Recently Used)알고리듬이 좋은 것으로 알려져 있으나 사실 각
페이지마다 참조 카운터(reference counter)를 유지하는 것은 많은 CPU 시스템
자원이 소모된다. 그래서 유닉스에서는 간단히 시계(clock) 알고리듬을 사용한
다. 커널은 페이징 아웃되는 메모리 페이지들을 가리키는 Free List를 유지한
다. 그리고 페이징 아웃될 페이지에 대한 지정 순서는 어느 메모리 페이지나
동일하게 순차적으로 지정된다. 그래서 시계의 시침이 돌아가듯 순차적이란 의
미에서 시계 알고리듬이라고 한 것이다. 하지만 메모리의 상태에 따라 시침이
돌아가는 속도는 변경된다는 점이 일반 시계와는 다른 점일 것이다.

메모리 사용 분석하기
워크스테이션의 경우 가장 좋은 메모리 분석 도구는 사람의 귀이다. 많은 페이
징이 일어나는 경우 하드 디스크를 스왑핑(swapping)하는 소리를 직접 확인할
수 있다. 페이징을 위한 스왑 공간의 확인은 BSD 시스템의 경우는 ‘pstat -
s’ 명령, ATT의 경우 ‘swap -l’ 명령을 이용한다. ATT의 경우 ‘sar -
r’ 명령도 사용할 수 있다. 사용예는 다음과 같다.
pstat 명령의 경우는 kbytes단위로 나타내고 다른 명령들은 512bytes 단위이다.

% pstat -s
110224k allocated + 13556k reserved =
123780k used, 163000k available

% swap -l
swapfile dev seapl blocks free
/dev/dsk/c0t0d0s1 32, 1 16 164400 162960

% sar -r 5
17:58:52 freemem freeswap
17:58:57 361 179616

HP-UX 시스템의 경우 스왑 영역에 대한 정보를 얻기 위해 swapinfo 명령을
사용한다.
OSF/1 시스템의 경우 sar 명령은 옵션으로 설치하기 때문에 대부분 없는 경우
가 많다. 하지만 스왑 상태를 확인하기 위해서는 ‘swapon -s’ 명령을 사용
하면 된다.

% swapon -s
Swap partition /dev/rz24b (default swap):
Allocated space: 98205 pages (767MB)
In-use space: 6320 pages ( 6%)
Free space: 91885 pages ( 93%)


Total swap allocation:
Allocated space: 98205 pages (767MB)
Reserved space: 9736 pages ( 9%)
In-use space: 6320 pages ( 6%)
Available space: 88469 pages ( 90%)

다음, BSD시스템과 HP-UX에서의 페이징 상태는 vmstat 명령을 사용하여 확
인한다.

% vmstat 5 5
procs memory page disk faults
cpu
r b w avm fre re at pi po fr de sr d0 d1 d2 d3 in sy cs us
sy id
0 0 0 0 2300 0 3 0 0 0 0 0 1 0 0 0 14 4 2 0
0 99
0 0 0 0 2116 0 9 24 0 12 0 10 1 0 0 0 17 104 8 0
0100
0 0 0 0 2064 0 2 0 0 0 0 2 0 0 0 0 10 39 3 0
0100
0 0 0 0 2048 0 0 0 0 0 0 0 0 0 0 0 7 15 0 0
0100
0 0 0 0 2048 0 0 0 0 0 16 0 13 1 0 0 33 13 8 1
1 98

procs 항목은 현재 수행을 기다리는 작업 수(r)와 I/O 블록된 프로세스(b), 현
재 스왑핑중인 프로세스(w) 수를 나타낸다. 스왑핑중인 프로세스의 수가 0이
아닌 경우 현재의 부하에 비해 메모리가 부족함을 의미하는 것이다.
memory 항목에서는 메모리의 상태를 보여주는데 최근 20초 안에 수행된 프로
세스에 속하는 가상 메모리의 kbytes 수(avm)와 여유 메모리 kbytes량(fre)을
확인할 수 있다.
page 항목은 페이징 활동에 대한 정보를 제공한다. 모든 열은 초당 평균값을
나타내는데 그 의미는 다음과 같다.

필드 항목 의미
procs r 현재 수행을 기다리는 작업 수
b I/O 블록된 프로세스 수
w 현재 스왑핑중인 프로세스 수
memory avm 최근 20초 안에 수행된 프로세스에 속하는
가상 메모리의 kbytes 수(avm)
fre Free List에 있는 메모리의 kbytes 수
page re 사용중인 페이지 수
at Free List에 있는 페이지 수
pi 페이지 인된 kbyte
po 페이지 아웃된 kbyte
fr Free List에 있는 kbytes
de 메모리 부족이 예상되는 페이지 수
sr clock 알고리듬에 의해 체크된 페이지 수

이 가운데 de 항목이 100을 넘어서면 메모리가 상당히 부족함을 의미한다. 하
지만 불행히도 많은 시스템들이 이 항목을 보여주지 않는다. ‘vmstat -S’와
같이 사용하면 페이지의 인, 아웃 대신 컨텍스트 스위치(context switch)에 대
한 항목을 보여준다. 다음과 같다.

% vmstat -S 5 5
procs memory page disk faults
cpu
r b w avm fre si so pi po fr de sr d0 d1 d2 d3 in sy cs us
sy id
0 0 0 0 7608 61 0 0 0 0 16 0 1 0 0 0 14 4 2 0
0 99
0 0 0 0 7584 25 0 0 0 0 0 0 0 0 0 0 13 38 4 0
0100
0 0 0 0 7520 0 0 0 0 0 0 0 0 0 0 0 4 15 0 0
0100
0 0 0 0 7504 0 0 0 0 0 0 0 0 0 0 0 1 6 0 0
0100
0 0 0 0 7504 0 0 0 0 0 0 0 0 0 0 0 5 11 3 0
0100

솔라리스의 경우는 ‘sar -g’ 옵션을 통해 페이지 아웃에 대한 정보를 확인
하며 페이지 인에 대한 정보는 ‘sar -p’ 명령을 사용한다.

디스크 I/O 분석하기
대부분의 시스템들은 iostat 명령을 통해 디스크 I/O 양을 모니터링 할 수 있
다. vmstat 명령과 같이 시간간격과 요약 횟수를 인자로 지정한다.

% iostat 5 5
tty wd0 sd0 cpu
tin tout sps tps msps sps tps msps us ni sy id
2 9 2 0 0.5 3 0 20.3 0 0 0 99
1 252 0 0 0.0 614 40 16.9 27 0 14 59
1 321 0 0 0.0 511 45 16.7 17 0 12 71
0 15 0 0 0.0 419 27 19.9 11 0 8 80
1 191 0 0 0.0 3 0 25.0 0 0 0 99

사실 iostat 명령에 대한 출력 결과는 시스템에 따라 다소 차이를 보인다. 하지
만 일반적인 위의 출력 결과에 대해 설명하도록 하겠다. tty 필드는 터미널과
가상 터미널에 대한 데이터를 나타낸다. 모든 터미널의 문자 입출력에 대한 초
당 횟수를 나타내는데 실제 시스템의 성능과는 별 연관이 없으며 특별한 목적
에만 유용하다. 각 하드 디스크는 sps, tps, msps 항목을 가진다. 각각 초당 전
송 섹터, 초당 전송 횟수, 탐색속도(밀리초)를 나타낸다. sps와 tps의 비는 한번
에 얼마나 큰 사이즈의 블록이 전송되는지를 나타내게 된다. 이 경우 크면 클
수록 성능 면에서는 효과적인 것이다.

항목 설명
tty tin 터미널에서의 초당 문자 입력 횟수
tout 터미널에서의 초당 문자 출력 횟수
sd,wd sps 초당 전송 섹터 수
tps 초당 전송 횟수
msps 탐색 속도(seek time: ms)

SunOS 4.1의 경우 이 비율도 나타내도록 ‘iostat -D’ 옵션을 줄 수 있다.

% iostat -D 5 5
sd0 sd1 sd2
rps wps util rps wps util rps wps util
0 0 1.3 0 0 0.3 0 0 0.5
9 8 41.1 1 0 1.8 1 0 2.4
11 4 48.4 0 1 2.0 0 0 0.0
8 0 15.6 0 0 0.0 0 0 0.0
0 0 0.0 0 0 0.0 0 0 0.0

파일 시스템 튜닝하기
tunefs 명령어가 파일 시스템의 여러 옵션을 조정하는데 사용된다는 것은 디
스크 공간 관리에 대한 연재에서 설명하였다. 다시 부연 설명하자면 tunefs 명
령어는 특정 파일 시스템의 전체적인 파라미터를 변경하는 일을 수행한다. 해
당되는 파라미터는 다음과 같은 것들이 있다.
(1) 파일에서의 블록 그룹간의 rotational delay
(2) 하나의 입·출력동안 전송되는 최대 블록 수
(3) 하나의 실린더 그룹에서 사용 가능한 블록 수
(4) 만약을 위해 준비하는 디스크 용량

가끔은 이 명령을 이용한 튜닝이 상당한 성능 개선 효과를 가져오는 경우가 있
다. 하지만 적절한 옵션의 조절을 위해서는 여러 번의 시도가 이루어져야 하며
항상 성능 개선 효과를 가져다주는 것도 아니므로 각 시스템들의 매뉴얼을 참
조하기 바란다.

pstat: 무작위 통계 출력하기(BSD)
BSD 계열에서 또 한 가지 유용한 명령어가 pstat 명령이다. 이 명령은 여러
가지 커널의 테이블의 데이터들을 사람이 읽기 쉬운 형태로 덤프해 준다.
다음은 BSD 시스템에서 사용하는 디스플레이 옵션을 나타낸 것이다. 다른 시
스템에서는 이보다 적은 옵션을 가지는 것이 일반적이다.

옵션 내 용
-i inode 테이블의 덤프
-x 텍스트(context swtich table) 테이블의 덤프
-P 프로세스 테이블의 덤프, ps 명령보다 자세하다
-f 개방된 파일 테이블의 덤프
-t 모든 터미널에 대한 정보를 나타냄
-u 특정 프로세스에 대한 정보를 나타냄
-s 스왑 공간에 대한 정보를 나타냄
-T 커널 테이블이 얼마나 차 있는지를 나타냄

이 중에서 가장 유용한 것이 -T 옵션으로 테이블의 사용 정보를 나타낸 것으
로 사용하면 다음과 같은 결과를 출력할 것이다.

% pstat -T
121/364 files
85/158 inodes
34/74 processes
21/38 texts
70/169 00k swap

물론 ‘현재 사용정도/전체 사용량’을 나타낸다. 이 옵션은 커널을 재구축하
는 경우 maxusers 옵션의 적절한 값을 지정하는데 도움을 준다.

시스템 성능 체크의 단계
시스템은 일시적으로 갑자기 느린 동작을 보이는 경우가 있다. 이러한 경우는
일반적으로 시간이 약간 경과하면 다시 원상태로 회복되지만 만약 이런 현상이
지속적으로 나타나면 다음과 같은 단계로 시스템을 체크해 보자.

ps 혹은 top 명령을 통해 zombie 프로세스나 혹은 시스템 자원을 굉장히
많이 소비하는 프로세스가 없는지 확인한다. CPU 사용을 50% 이상 사용하는
프로세스를 처리하고 만약 이러한 프로세스가 없을 경우는 10% 미만의 프로세
스가 여러개(3개이상) 있는지 검사한다. 검사는 uptime 명령을 사용해 평균 부
하를 체크하고 CPU가 계속 대기 상태인지를 vmstat나 ‘sar -u’ 명령을 통
해 확인한다.
CPU 사용상태에 문제가 없는 경우는 얼마나 많은 가상 메모리의 교체
(Paging)가 일어나는지 vmstat나 ‘sar -g’ 명령을 통해 확인한다. 많은 수의
교체가 일어난다는 것은 메모리에 대한 경쟁이 치열함을 의미하는 것이다. 만
약 페이징 없이 디스크 사용정도가 높게 나타나면 이는 하나의 프로세스가 파
일 입·출력을 하면서 디스크를 독점함을 의미하는 것이다. 이런 경우 그 프로
세스를 찾는 것은 사실 뾰족한 방법이 없는데 일반적으로 디스크 사용이 많은
프로세스는 CPU 사용도 많다는 정도가 도움이 될 것이다.
문제가 되는 프로세스를 찾았을 때 우선은 그 프로세스의 소유자에게 확인
한 후 그 프로세스의 우선 순위를 낮게 조정한다거나 혹은 제거하는 방법을 사
용해야 할 것이다. 물론 여기에는 사용자와의 인간적인 대화가 먼저 요구된다.
물론 불법적인 프로세스인 경우는 물어볼 필요 없이 제거하면 된다. 참고로
BSD 시스템의 경우는 setrlimit() 시스템 콜을 이용한 limit 명령을 통해 물리
적 메모리의 사용량을 제한할 수 있다. 사용예는 다음과 같다.

% limit memoyuse 2m

위의 예는 2MByte로 메모리 사용량을 제한하는 것이다.
시스템 성능저하의 원인이 프로세스 때문이 아니라면 다른 이유로 인해 발
생한 것으로 보면 되는데 첫 번째가 네트워크의 부하가 큰 경우이다. 두 번째
가 서버-클라이언트 관련된 프로그램에 의한 연결지연이 그 원인인데 이는 서
버가 다운된 경우 이를 접속하려는 클라이언트가 계속 연결지연을 하는 것이
그 원인인 것이다. 이러한 문제들은 네트워크 상태를 체크해 파악한 후 해결한
다.

마치며
사실 시스템 튜닝은 그 원인도 상당히 다양할뿐더러 시스템 특성을 타기 때문
에 일반적인 방법도 그리 도움이 안되는 경우가 상당히 많다. 대부분 해당 시
스템에 대한 정보를 구석구석 알아두고 여러 네트워크 환경도 미리 파악해 두
는 것이 도움이 되는 정도일 것이다. 또하나 중요한 것은 튜닝 경험이다. 독자
여러분들도 지속적인 연습을 평소 해두기 바란다.
정말 길고도 짧은 연재가 끝나는 시점에 와서 보니 솔직이 시원섭섭하다. 독자
여러분들에게 어줍잖은 글을 쓰면서 연재가 별 도움이 되었을지 모르겠다. 하
지만 이 글을 읽고 도움을 받은 독자가 한 사람이라도 있다면 그것으로 필자는
만족한다. 사실 매달 프세가 나오면 항상 후회를 했다. 더 잘 쓸 수 있었을 텐
데 하는 아쉬움이 남는다. 혹시라도 다음에 독자 여러분과 다시 글로 만날 기
회가 주어진다면 더욱 좋은 글을 쓰고 싶다. 그럼 언제나 노력하는 여러분이
되길 바라며 글을 맺는다.