[펌] Solaris Memory 관리

2. Memory Doc Rev: 2.0   junsoft.com 2.1   가상 메모리(Virtual Memory) Solaris는 가상 메모리(Virtual Memory) 시스템을 사용한다. 가상 메모리 시스템이란 물리적 메모리(physical memory)와 하드 디스크(swap device)를 결합하여 하나의 큰 메모리 처럼 사용하는 것을 말한다. 즉, 물리적 메모리가 100M 이고 swap device가 100M이면 가상 메모리량은 약 180MB 정도 된다. physical memory + swap device - VM management overhead = swap(VM) == simple == (physical memory + swap device) * about 90% ~= swap(VM) (100M + 100M) * 0.9 ~= 180M Solaris는 이러한 가상 메모리를 관리하기 위하여 메모리를 페이지 단위(8KB)로 나누어 관리한다. 이러한 페이지들을 모아서 세그먼트로 구성하여 사용한다. 프로세스가 동작하기 위해서는 그 프로세스가 필요한 메모리가 있다. 그러나 그 메모리가 물리적 메모리에 모두 적재되어야 실행되는 것은 아니다. 프로세스가 실재 액세스하는 메모리만 물리적 메모리에 적재되어 있어도 프로세스는 실행된다. 그런데 여유 있는 물리적 메모리가 없어서 프로세스에게 필요한 메모리를 줄 수 없을 때 커널은 현재 사용하고 있는 물리적 메모리 중에 최근에 사용되지 않은 메모리를 선택하여, (필요하면, 선택된 메모리를 swap partition에 저장하고) 그 메모리를 그 프로세스에게 준다. Solaris에서는 가상 메모리(Virtual Memory)를 swap으로 명칭한다(swap partition과 구별해 주십시오). 이 swap(VM)은 운영체제가 사용할 수 있는 메모리이다. vmstat 명령어의 4번째 필드 swap은 사용 가능한 가상 메모리의 크기를 KB 단위로 나타내고 5번째 필드 free는 사용 가능한 물리적 메모리(Physical Memory)를 KB 단위로 나타낸다. 가상 메모리에 대한 자세한 사항은 다음과 같이 swap -s 명령어로 알 수 있다. # swap -s total: 664720k bytes allocated + 53320k reserved = 718040k used, 485160k available swap 공간에서 718040KB가 사용되고, 485160KB?사용 가능하다. 사용된 718040KB 중에서 실재 할당 받아서 사용한 것은 664720KB이고 53320KB는 예약된 메모리 이다. 할당 받은 것과 예약한 것의 차이는 다음과 같다. 만일 프로세스가 데이타를 관리하기 위하여 10MB의 메모리가 필요하여 10MB의 메모리를 요청했다면 10MB의 메모리가 그 프로세스가 사용할 수 있도록 예약해 둔다. 그리고 그 프로세스가 메모리를 실재 액세스할 때, 그 메모리가 할당된다. 예를 들어 10MB 메모리를 요청하여 1MB의 메모리만 액세스하였다면, 1M은 allocated된 영역에 더 해지고, 9MB는 reserved 영역에 더 해진다. 응용 프로그램이 동작할 때, 필요한 메모리는 swap(VM)에서 가져온다. 물리적 메모리가 많든 적든 관계없이 swap 공간이 충분하면 프로그램이 실행되는 데에는 전혀 문제가 없다. 만일 물리적 메모리가 절대적으로 부족하다면, 실행속도가 늦어질 뿐, 메모리 부족으로 애플리케이션이 중단되는 일은 없다. swap partition에 대한 정보는 다음과 같이 swap -l 명령어로 확인할 수 있다. # swap -l swapfile dev swaplo blocks free /dev/dsk/c0t0d0s1 151,1 16 1638992 933104 blocks은 전체 swap partition의 크기이며 512 바이트 단위의 블럭이고, free는 그 중에 사용 가능한 swap partition의 크기이며 512 바이트 단위의 블럭이다. 즉, (blocks - free) / 2 = 현재 스왑 아웃된 양(KB) 위의 swap -l 명령어의 결과에서 보면, 352944KB의 메모리가 swapout 되었음을 알 수 있다. (1638992 - 933104) / 2 = 352944KB ~= 344.67MB 실제 swap이 좀 더 구체적으로 어떻게 관리되는지 자세히 알아보자. available swap(VM) = DSP (disk swap partition) + PM (physical memory) ( DA ) + ( MC + MA ) * Memory allocation: reserved allocated 1. request: p = malloc( 100MB ); 100M 0M 2. use: for( i = 0; i < 10M; i++ ) *(p+i) = 1; 90M 10M 첫번째 프로세스가 메모리를 요청하면, 요청한 메모리 만큼 예약하여 둔다. 그리고 그 메모리를 실재로 액세스할 때 그 메모리가 물리적 메모리에 할당된다. vmstat 명령어의 결과물에 있는 다음과 같은 필드와 함께 Solaris 메모리 관리 방법을 설명한다. # vmstat 1 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr aa dd s1 s4 in sy cs us sy id 0 0 0 952128 87416 0 24 35 0 0 0 0 0 2 0 1 264 1327 272 7 2 90 0 0 0 931344 48384 0 2 0 0 0 0 0 0 0 0 0 204 191 94 0 1 99 0 0 0 931344 48384 0 137 0 0 0 0 0 0 0 0 0 204 449 102 12 2 86 swap:  amount of swap space currently available (Kbytes) free:  size of the free list (Kbytes) re:  page reclaims mf:  minor faults pi:  kilobytes paged in po:  kilobytes paged out fr:  kilobytes freed de:  anticipated short-term memory shortfall (Kbytes) sr:  pages scanned by clock algorithm Solaris에서 여유 있는 물리적 메모리를 화일 시스템의 캐쉬로 사용한다. 디폴트로 프리 메모리(free physical memory)가 전체 물리적 메모리 양의 1/64(lotsfree)보?크면, 화일 시스템을 통한 디스크 I/O는 모두 메모리에 남겨두어 화일 시스템의 캐쉬로 사용한다. 프리 메모리가 물리적 메모리 양의 1/64보다 적으면, Solaris는 프리 메모리를 1/64로 채우기 위하여 시스템에 있는 페이지를 조사하여, 최근에 사용되지 않은 페이지를 찾아서 프리시킨다. 이때 운영체제가 조사한 페이지의 갯수가 sr(scan rate)값이다. sr값이 높으면(30초 단위로 측정한 값이 초당 200-300 이상), 그 순간에 메모리가 부족하다고 판단할 수 있다. 프리시킨 페이지 수는 KB 단위로 환산되어 fr(free)에 보여준다. 페이지를 프리시킬 페이지의 내용이 변경되었을 경우, 그 페이지를 disk에 저장한다. (변경된 페이지가 프로그램의 데이타일 경우, 스왑 파티션에 저장되고, 화일 시스템의 케쉬이면 해당 디스크 파티션에 저장된다.) 이때, 디스크에 저장된 페이지를 KB 환산하여 po(page out)에 보여준다. Solaris에서 화일 시스템은 페이지 서브 시스템을 통하여 이루어 진다. 즉, 화일 시스템의 입출력은 모두 page I/O로 이루어 진다. 화일 시스템을 통하여 화일을 읽을 때, 읽은 양은 KB로 환산되어 pi(page in)에 보여준다. 프로그램을 실행할 경우에 운영체제는 프로세스에 대한 어드레스 맵핑 테이블을 만들고, 프로세스를 실행한다. 프로세스가 실행되다가 필요한 페이지가 자신의 어드레스 맵핑 테이블에 연결되어 있지 않으면, 페이지 폴트가 발생하는데, 그 페이지가 메모리에 있으면(minor page fault라고 함), 그 페이지를 자신의 어드레스 맵핑 테이블에 등록한다. vmstat의 mf(minor fault)는 minor page fault 횟수를 나타낸다. 프리 메모리가 부족할 경우, paging이 발생하여 최근에 사용되지 않은 페이지를 찾아서 프리시켜 부족한 메모리를 보충하게 되는데, 이렇게 프리되는 페이지의 내용은 훼손되지 않고 프리 메모리 영역에서 관리된다. 이렇게 프리된 페이지가 프로세스의 요청에 따라 다시 사용될 수 있다. 이렇게 다시 사용된 페이지 수를 re(reclaim)에 보여준다. 페이지의 크기는 pagesize 명령어로 확인할 수 있다.(sun4u 시스템은 8KB이고 sun4m은 4KB이다) # pagesize 8192 특별히 메모리를 많이 사용하는 프로그램이 없는데도, 보통 Solaris 시스템의 free memory의 크기가 아주 작게 보인다. 이것은 정상적이라고 말할 수 있다. 이것은 앞에서 설명한 바와 같이 화일 시스템의 캐쉬로 많은 부분이 사용되고 있기 때문이다. 이것을 테스트해 볼 수 있는 방법으로 다음과 같이 할 수 있다. 시스템을 부팅한 직후에는 free memory가 많이 남아 있다. 이 상태에서 화일 시스템 I/O를 많이 발생시키는 tar 명령어를 다음과 같이 실행시키면서 vmstat 명령어로 free memory가 어떻게 줄어 드는지 살펴 보십시오. # tar cvf /dev/null / ... skip ... tar 명령어가 루트 디렉토리에서 부터 모든 화일을 읽어 들여서 /dev/null로 저장한다. /dev/null은 특수화일이고, 이 곳에 쓰기를 하면 그 내용은 없어진다. (Solaris 8부터는 메모리 관리 기법이 조금 다르다. 여기서 기술하는 내용은 Solairs 7 이하에 대하여 언급한다) 다음은 vmstat 명령어의 결과물에서 메모리 관련 값에 대하여 설명한다. 2.2   메모리 튜닝 파라메터 메모리 튜닝 파라메터에는 다음과 같은 것이 있다. 이 값을 잘 못 수정하면, 시스템에 안 좋은 영향을 줄 수 있다. 그러므로 메모리 관리 기법에 대하여 충분한 지식이 없는 경우, 아래에 열거하는 파라메터를 수정하지 않은 것이 바람직 하다. 여기서는 메모리 관리 방법을 이해하기 위하여 설명한다. cachefree: cachefree는 priority_paging이 설정되어 있는 경우에 사용되며, 디폴트로 lotsfree의 2 배로 설정되어 있다. 커널은 자유메모리(free memory)가 cachefree 보다 적을 경우, cachefree 만큼 유지하기 위하여 시스템에서 최근에 사용되지 않았던, 메모리를 찾아서 프리시키고, 그 메모리를 자유 메모리에 포함시킨다. 이때, 프리시킬 페이지를 찾기 위해서 커널은 물리적 메모리를 다음과 같은 4가지의 분류로 관리한다. 1. 프로세스의 코드 (process's code) 2. 프로세스의 데이타 (process's data) 3. 화일 시스템의 캐쉬 (file system cache) 4. 자유 메모리 (free memory) 여기서 자유 메모리가 cachefree 보다 작고, lotsfree 보다 크면, 프리시킬 메모리를 화일 시스템의 캐쉬 중에 최근에 사용하지 않은 페이지를 찾는다. cachefree 보다 적은 부족분을 채우기 위해서 초당 일정량의 페이지를 조사한다. (slowscan, fastscan 참조) lotsfree + pages_before_pager: pages_before_pager는 디폴트로 200 설정되어 있다. 만일 자유 메모리가 lotsfree + pages_before_pager 보다 적을 경우, 다음과 같이 동작한다. - write 수행한 페이지를 프리시킨다. - UFS와 NFS 화일 시스템에서 sequential read한 페이지를 프리시킨다. - NFS에서 read-ahead 기능을 중단한다. - NFS write를 synchronous write 한다. lotsfree: lotsfree는 디폴트로 물리적 메모리의 1/64로 설정되어 있다. 만일 자유 메모리가 lotsfree보다 적을 경우에는 메모리의 분류와 상관없이 최근에 사용되지 않았던 메모리를 찾아서 프리시킨다. 이 경우에 프리시킬 메모리가 프로그램의 데이타이고 그 내용이 변경되어 있다면, 그 내용은 swap partition에 저장된다. desfree: desfree는 디폴트로 lotsfree의 1/2로 설정되어 있다. 자유 메모리의 크기가 최근 30초 동안 평균이 desfree보다 적으면, NFS version3 write operation이 중지되고, kernel async I/O도 중지되고, idle process(maxslp(20) 이상 sleep한 프로세스)는 swap out된다(Soft swaping). 이때 Swap out된 프로세스의 정보가 vmstat의 w 컬럼에 보여진다. w의 값은 쓰레드(thread)의 갯수이다. 멀티 쓰레드 프로세스가 아닌 경우에는 하나의 프로세스는 하나의 쓰레드를 가진다. 한번 swap out된 프로세스는 그 프로세스가 다시 실행될 때 메모리로 들어온다. 예를 들어, 프린터 데몬 lpsched가 swap out되었다면, 프린터를 사용하는 작업을 하지 않은 한 메모리로 들어오지 않는다. minfree: minfree는 디폴트로 desfree의 1/2로 설정되어 있다. 만일 run queue에 2개 이상의 프로세스가 CPU를 사용하기 위하여 대기하고 있고, 자유 메모리의 크기가 최근 30초 동안 평균이 desfree보다 작고, 최근 5초 동안 평균이 minfree보다 작고, 페이지 I/O가 과도하게(pagein+pageout > maxpgio) 발생하면, 현재 엑티브하지 않은 커넬 모듈과 화일 시스템의 캐쉬를 프리시키고, 그래도 부족한 메모리를 확보하지 못 하면 프로세스를 추가적으로 swap out한다(Hard swaping). throttlefree: throttlefree는 디폴트로 minfree의 값으로 설정되어 있다. 치명적인 메모리 요구를 제외한 메모리 요청은 중단된다(blocked). pageout_reserve: throttlefree는 디폴트로 throttlefree의 1/2로 설정되어 있다. 모든 메모리 요청이 중단된다(blocked). (pageout and sched thread 제외) slowscan: fastscan: slowscan은 디폴트로 100이다 fastscan은 디폴트로 8192이다 물리적 메모리가 lotsfree 이하로 떨어지면, 부족한 메모리를 보충하기 위하여 일정량의 페이지를 조사한다. 조사할 페이지 수는 부족한 메모리의 양에 따라 slowscan과 fastscan사이의 페이지 수에서 결정된다. 이렇게 결정된 페이지는 1/4씩 page scanner에 의해 1초에 4 차례씩 페이지 수를 조사한다. page scanner가 페이지를 조사할 때, 최대로 사용할 수 있는 CPU 사용율은 CPU 한 개의 95% 이다. 부족한 페이지가 보충된 경우에 scan을 중단한다. maxpgio: 초당 page out할 수 있는 최대 페이지 수 handspreadpages: handspreadpages는 디폴트로 fastscan 값으로 설정되어 있다. 클럭 알고리즘에서 front hand와 rear hand사이에 있는 페이지 수 Solaris에서 부족한 메모리을 보충하기 위하여 기존에 사용하고 있던 페이지 중에 최근에 사용하지 않은 페이지를 찾아서 프리시킨다. 최근에 사용하지 않은 페이지를 찾는 방법으로 Solaris에서 클럭 알고리즘을 사용한다. 시스템에 있는 모든 메모리를 연결하여 원을 만들고 시계처럼 두개의 바늘을 둔다. 그 중에 앞 바늘과 뒷 바늘과의 간격이 handspreadpages 이다. 시스템에 물리적 메모리가 부족하면 page scanner 기동한다. 이때 두시계 바늘을 동시에 움직이면서 front hand는 해당 페이지의 access bit를 클리어하고 rear hand는 그 해당 페이지에 access bit가 설정되어 있는지 조사하여 access bit가 설정되어 있지 않으면 그 페이지를 프리시킨다. access bit는 해당 페이지를 access하면 H/W MMU에 의해 자동으로 설정된다. priority_paging: priority paging을 사용하려면, 다음과 같은 내용을 /etc/system 화일에 넣고 시스템을 리붙하면 된다. set priority_paging = 1 priority paging을 사용하면, scan rate가 좀 더 높아진다. 그러나 페이지를 프리할 때, 화일 시스템의 케쉬를 먼저 프리하기 때문에 프로그램의 데이타나 코드가 보호되어 시스템 성능이 향상된다. Solaris 8에서는 새로운 캐쉬 메카니즘을 사용한다. 또한 priority paging을 지정하면 안 된다. Solaris 8에서는 케쉬로 사용되고 있는 물리적 메모리를 free memory에 포함시킨다. 2.3   시스템 메모리 사용량 확인 시스템이 사용하고 있는 메모리를 확인할 수 있는 시스템 명령어로는 다음과 같은 명령어들이 있다. # swap -s total: 482240k bytes allocated + 47560k reserved = 529800k used, 674056k available # vmstat 1 2 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr aa dd f0 s1 in sy cs us sy id 0 0 6 1464 4184 0 4 2 0 3 0 1 0 0 0 0 211 715 191 5 1 94 0 0 18 673968 16072 0 2 0 0 0 0 0 0 0 0 0 204 514 199 0 0 100 # sar -r 1 1 SunOS king 5.6 Generic_105181-25 sun4u 12/22/01 09:56:19 freemem freeswap 09:56:20 1922 1308132 사용 가능한 가상 메모리는 각각의 명령어의 결과에서 확인할 수 있다. swap -s vmstat sar -r ------------------------------------------------ 674056KB 673968KB 1308132 Block(=654066 KB) 사용 가능한 물리적 메모리는 vmstat의 free(단위 KB)와 sar -r의 freemem(단위 Page)에서 확인할 수 있다. free = freemem * pagesize in Kilobye (UltraSparc의 pagesize는 8KB이다) free = freemem * 8 Parm에 포함된 perfmon과 ParmView의 SWAP(단위 MB)과 FREE(단위 MB)에서도 확인할 수 있다. 2.4   프로세스 메모리 사용량 확인 프로세스가 사용하는 메모리 양은 다음과 같은 시스템 명령어로 확인할 수 있다. # /usr/bin/ps -eafl F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 8 S guest 19345 19325 0 51 20 623ab780 1176 616138ae Dec 14 ? 5:11 dtwm 8 S guest 10699 19347 0 61 20 62ee1678 218 62ee16e8 14:29:07 pts/11 0:00 /bin/ksh ... skip ... # /usr/ucb/ps -aux USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND guest 19345 0.5 1.6 9408 7968 ? S Dec 14 5:10 dtwm guest 10699 0.0 0.3 1744 1368 pts/11 R 14:29:07 0:00 /bin/ksh ... skip ... 프로세스가 사용하고 있는 메모리 양는 /usr/bin/ps의 SZ(단위 Page)와 /usr/ucb/ps의 SZ(단위 KB)이다. 그리고 /usr/ucb/ps의 RSS는 프로세스의 메모리(SZ) 중에서 물리적 메모리에 로드된 메모리 양이다. 또한 Parm에 포함된 psinfo 명령어에서도 확인할 수 있다. psinfo 명령어에는 HP+STK라는 항목이 있는데, 이것은 프로세스의 heap과 stack를 더한 양이다. heap과 stack은 프로세스가 실행되면서 다이나믹하게 할당 받는 공간이며, 다른 프로세스들과 공유되지 않는 공간이다. 프로세스가 실행되면서 다이나믹하게 메모리를 할당 받으면, 그것은 heap 영역에 잡힌다. 메모리 관리를 잘 못 하는 프로세스가 있는지 여부를 판단하기 위해서는 heap 영역의 크기가 얼마인지를 먼저 확인하여야 한다. 그 프로세스가 동작하는 역할에 비하여 너무 많은 heap 영역을 사용하면 메모리 관리에 오류가 있을 가능성이 높다. Parm의 psinfo 명령어에서 -h 옵션을 사용하면, HP+STK가 큰 순서로 정렬하여 보여준다. 또한 psinfo 명령어의 header에는 전체 프로세스가 사용하는 HP+STK를 합계한 정보도 보여준다. # /opt/JSparm/bin/psinfo -h Date.time 1207.17:34:23 proc 518 zomb 339 run 0 lwp 422 cpu 10.06% load1m 0.11 ptime 128742.41 hp+stk 250.1M PID PPID USERNAME SIZE RSS HP+STK S NLWP WCPU% CPU% MEM% ELAPSED TIME CMDLINE 11455 10585 guest 70.35M 60.51M 48.71M S 1 2.34% 2.34% 12.2% 1d10496 16:06.70 netscape 29795 1 guest 92.63M 76.16M 34.40M S 17 4.06% 4.06% 15.4% 3d25550 02:46:58.48 senddata -p 1200 29135 29110 guest 34.92M 16.95M 27.82M S 1 0.27% 0.27% 3.4% 3d30359 02:14.12 recvdata -p 1201 323 322 nobody 46.03M 7.164M 27.07M S 71 0.00% 0.00% 1.4% 24d3926 34.04 checkdata 29320 29319 guest 38.35M 24.10M 26.02M S 12 0.00% 0.00% 4.9% 3d29489 03:28.75 /usr/dt/bin/dtmail 17664 395 root 56.68M 41.97M 16.44M S 1 2.06% 2.06% 8.5% 8d84118 23:52.56 savelog -f sv.conf ... skip ... SIZE와 RSS와 HP+STK 크기 관계는 다음과 같다. SIZE >= RSS SIZE > HP+STK RSS와 HP+STK와의 크기에 대한 상관관계는 없다. 프로세스의 메모리 상태를 좀 더 자세히 보고 싶으면, pmap 명령어를 사용할 수 있다. # /usr/proc/bin/pmap -x 10699 10699: /bin/ksh Address Kbytes Resident Shared Private Permissions Mapped File 00010000 184 184 184 - read/exec ksh 0004C000 8 8 - 8 read/write/exec ksh 0004E000 56 56 - 56 read/write/exec [ heap ] EF580000 592 584 584 - read/exec libc.so.1 EF622000 32 32 - 32 read/write/exec libc.so.1 EF62A000 8 8 - 8 read/write/exec [ anon ] EF650000 64 64 64 - read/exec ko.so.1 EF66E000 8 8 - 8 read/write/exec ko.so.1 EF680000 456 424 368 56 read/exec libnsl.so.1 EF700000 40 40 8 32 read/write/exec libnsl.so.1 EF70A000 16 8 - 8 read/write/exec [ anon ] EF720000 8 8 8 - read/exec methods_ko.so.1 EF730000 8 8 - 8 read/write/exec methods_ko.so.1 EF740000 16 16 16 - read/exec libc_psr.so.1 EF750000 16 16 16 - read/exec libmp.so.2 EF762000 8 8 - 8 read/write/exec libmp.so.2 EF780000 8 8 - 8 read/write/exec [ anon ] EF790000 32 32 32 - read/exec libsocket.so.1 EF7A6000 8 8 - 8 read/write/exec libsocket.so.1 EF7A8000 8 - - - read/write/exec [ anon ] EF7B0000 8 8 8 - read/exec libdl.so.1 EF7C0000 128 128 128 - read/exec ld.so.1 EF7EE000 16 16 - 16 read/write/exec ld.so.1 EFFFC000 16 16 - 16 read/write [ stack ] -------- ------ ------ ------ ------ total Kb 1744 1688 1416 272 2.5   Q & A   2.5.1   특별히 메모리를 많이 사용하는 것이 없는데 메모리 양이 매우 적게 보입니다. 위에서 언급한 바와 같이 Solaris 운영체제는 물리적 메모리의 여유 공간을 화일 시스템의 캐쉬로 사용한다. 애플리케이션 프로그램이 화일을 읽고 쓸 경우, 커널 메모리를 거쳐서 I/O가 발생한다. 이때 화일을 읽거나 쓴 후에, 커널 메모리에 남아 있는 화일의 내용을 바로 지우는 것이 아니고, 캐쉬 용도로 사용하기 위하여 메모리에 남겨둔다. I/O가 많이 발생하면 화일 시스템의 캐쉬가 시스템의 메모리를 다 사용하게 될 것이다. 이것을 관리하기 위하여 커널은 물리적 메모리 양이 lotsfree(전체 물리적 메모리 양의 1/64(1.5%)) 이하로 줄어들 경우에 시스템에 있는 메모리를 조사하여 최근에 사용하지 않은 페이지를 찾아, 프리시켜서 lotsfree 양 만큼의 메모리를 유지한다. 그래서 일반적으로 시스템의 물리적 메모리의 양은 적게 보인다. 이것으로 시스템의 메모리가 부족하다고 판단할 수 없다. 일반적으로 시스템의 메모리가 부족하다고 판단할 수 있는 근거는 scan rate의 값으로 판단한다. 30초 간격으로 조사하여 약 200 - 300 이상이면 그 순간에 메모리 로드가 있다고 판단한다. priority_paging을 사용하면 메모리 양이 cachefree(전체 물리적 메모리 양의 1/32(3%)) 보다 적게되면, 시스템이 있는 메모리를 조사하여 최근에 사용하지 않은 페이지를 찾아, 프리시켜서 cachefree 양 만큼의 메모리를 유지한다. 메모리가 lotsfree 양보다 클 경우에는 화일 시스템의 캐쉬로 사용되는 메모리만 프리시킨다. priority_paging가 사용되면, scan rate 값이 좀 더 크게 측정될 수 있다. (Solaris 8에서는 화일 시스템의 캐쉬로 사용되는 메모리을 물리적 메모리 사용량으로 포함시키지 않는다.)   2.5.2   어떤 프로세스가 메모리를 비정상적으로 많이 사용하는지 알 수 있읍니까? 애플리케이션 프로그램을 작성하면 프로그램이 사용하는 코드나 초기 데이타의 크기는 고정된다. 그리고 프로그램이 실행되어 프로세스로서 동작하게 되면 다이나믹하게 메모리를 할당 받을 수 있는데, 일반적으로 비정상적으로 메모리를 사용하는 프로세스는 다이나믹하게 메모리를 할당 받고, 그것을 제대로 관리하지 않아서 발생한다. 이렇게 할당 받은 데이타는 프로세스의 힙(heap) 영역에 포함된다. 따라서 힙(heap)이 큰 프로세스가 있다면, 그 프로세스가 그 만큼의 힙(heap)을 사용할 프로세스인지 아니지를 판단하여야 한다. 만일 비정상적으로 힙(heap)을 사용한다고 판단이 되면, 그 프로그램의 개발자에서 알려서 프로그램을 수정하여야 할 것이다. 프로세스가 얼마나 많은 힙(heap)을 사용하는가를 확인하려면, Parm에 포함된 psinfo 명령어로 확인할 수 있다. psinfo에 -h 옵션을 사용하면 힙(heap)을 많이 사용하는 순서로 화면에 보여준다. # /opt/JSparm/bin/psinfo -h Date.time 0123.12:27:07 proc 518 zomb 339 run 0 lwp 422 cpu 15.26% load1m 0.20 ptime 128706.45 hp+stk 249.9M PID PPID USERNAME SIZE RSS HP+STK S NLWP WCPU% CPU% MEM% ELAPSED TIME CMDLINE 19440 19438 guest 131.0M 84.38M 107.4M R 1 4.90% 4.90% 17.0% 8d73139 03:00:59.86 netscape 13217 13216 nobody 44.42M 10.82M 26.12M S 59 0.00% 0.00% 2.2% 1d7702 16.18 ns-httpd -d config 200 1 root 6.070M 1.555M 2.875M S 10 0.00% 0.00% 0.3% 58d11424 16.60 /usr/sbin/syslogd 283 1 oracle 63.89M 41.88M 2.547M S 1 0.00% 0.00% 8.5% 58d11409 09.85 ora_pmon_SOL 19345 19325 guest 9.258M 6.805M 2.141M S 7 0.68% 0.68% 1.4% 8d73245 05:59.89 dtwm 19904 19903 guest 7.172M 4.438M 1.594M S 1 0.00% 0.00% 0.9% 8d66806 09.37 dtpad -server 19339 1 guest 4.383M 3.250M 1.266M S 4 0.00% 0.00% 0.7% 8d73246 26.76 senddata -p 1200 285 1 oracle 63.02M 44.93M 1.258M S 22 0.00% 0.00% 9.1% 58d11409 02.33 ora_dbw0_SOL 287 1 oracle 62.78M 45.05M 1.203M S 14 0.00% 0.00% 9.1% 58d11409 02.66 ora_lgwr_SOL 289 1 oracle 62.72M 44.91M 1.172M S 11 0.00% 0.00% 9.1% 58d11409 02.42 ora_ckpt_SOL ... skip ... HP+STK는 프로세스의 힙(heap)과 스택(stack)을 합계한 크기이다. 만일 프로세스의 메모리 크기 순서(SIZE)로 정열할 경우에 oracle과 같이 큰 공유메모리를 사용하는 프로세스가 있다면, 그 프로세스들이 상위를 차지할 것이다. 전체 크기(SIZE)로 보아서는 그 프로세스가 얼마나 많이 다이나믹한 메모리를 할당 받았는지 알 수 없다. 프로세스 메모리 맵에 대한 자세한 정보는 /usr/proc/bin/pmap 명령어를 사용하여 확인할 수 있다.   2.5.3   vmstat의 w값이 30으로 계속해서 보입니다. vmstat의 w가 의미하는 것은 swap out된 쓰레드(thread) 갯수를 나타내며, 멀티 쓰레드 프로세스가 아닌 경우에는 하나의 프로세스는 하나의 쓰레드를 가진다. 한번 swap out된 프로세스는 그 프로세스가 다시 실행될 때 메모리로 들어온다. 예를 들어, 프린터 데몬 lpsched가 swap out되었다면, 프린터를 사용하는 작업을 하지 않은 한 메모리로 들어오지 않는다. vmstat의 w값에 0이 아닌 값이 나타날 무렵에 시스템의 메모리 로드가 극심했다는 것을 알 수 있다. 이렇게 메모리 로드를 극심하게 야기시킬 수 있는 경우는 다음과 경우가 있을 수 있다. 1. 프로세스를 동시에 많이 실행하여 메모리 요청이 집중되었을 경우 2. 화일 시스템 backup과 같이 광범위하게 많은 양의 화일을 동시에 액세스할 경우 3. 프로세스가 큰 메모리를 요구하여 짧은 시간에 초기화 할 경우   2.5.4   df -k 에서 swap의 크기가 변합니다 # df -k /tmp Filesystem kbytes used avail capacity Mounted on swap 845712 196248 649464 24% /tmp # ... skip .... # df -k /tmp Filesystem kbytes used avail capacity Mounted on swap 706336 196248 510088 28% /tmp 실제로 df -k 명령어에서 보여주려고 하는 값은 swap의 값이 아니라 /tmp의 값을 보여주려고 한다. / 화일 시스템의 저장공간은 하드 디스크의 특정 파티션(예, /dev/dsk/c0t0d0s0)이고 이 크기는 화일 시스템을 다시 만들기 전까지는 불변이다. 그러나 /tmp 화일 시스템의 저장공간은 하드 디스크의 특정 파티션이 아니고 가상 메모리를 저장공간으로 사용한다. / 화일 시스템은 ufs 라는 화일 시스템을 사용하는 반면에, /tmp 화일 시스템은 tmpfs 라는 특수한 화일 시스템을 사용한다. 이것은 화일 시스템의 저장공간으로 가상 메모리(VM: swap)를 사용한다. 그래서 프로세스들이 메모리를 많이 사용하면 가상 메모리 공간이 줄어든다. 그 결과 /tmp 디렉토리에 화일들이 더 이상 만들어 지지 않았음에도 불구하고 swap 공간이 줄어서 /tmp 디렉토리가 100%로 될 수 있다.   2.5.5   vmstat 명령어의 결과에서 프리 메모리량에 대하여 그래프를 만들 수 있읍니까? Parm에는 vmstat, iostat, mpstat, netstat, sar의 결과물에서 주요 필드에 대하여 그래프를 만들 수 있는 명령어들(gvmstat, giostat, gmpstat, gnetstat, gsar)이 있다. 뿐만 아니라, 행과 열로 된 데이타에 대하여 그래프를 만들 수 있는 명령어(mkgraph)가 있다. vmstat 명령어의 결과를 수집한 화일이 vmstat.log가 있고(09시 정각에 30초 간격으로 수집했다고 가정), 이 화일에 대하여 다음과 같이 free 메모리 그래프를 만들 수 있다. # gvmstat -t 09:00:00 -i 30 -G free -o output vmstat.log 위의 명령어는 output.gif 화일을 만든다. 다음은 output.gif의 내용이다.   2.5.6   swap -s 에서 실제로 할당된 메모리의 크기를 모니터하여 그래프를 그려볼 수 있읍니까? # swap -s total: 664720k bytes allocated + 53320k reserved = 718040k used, 485160k available swap -s 명령어를 실행하여 allocated 된 부분과 reserved 된 부분과 이 두개를 합계한 used 된 부분에 대하여 다음과 같이 그래프를 만들 수 있다. # dolog -o swap-s -t -T 30,480 swap -s # ls -l swap-s.021105.091020.30 # mkgraph -G 2::allocated,6::reserved,9::used -A -i 30 -t 091020 -o swap swap-s.021105.091020.30 # ls -l swap-s.021105.091020.30 swap.gif dolog 명령어는 Parm V6.1에 포함된 명령어이다. 이것은 지정한 명령어를 일정 시간간격으로 실행하여 그 결과을 화일에 저장한다. 이렇게 저장된 결과에 대하여 mkgraph 명령어로 그래프를 그린다. 다음은 swap.gif 화일의 내용이다.