시작하며..

리눅스 RAM 디스크에서 자바 컴파일(ant/ivy)하면 얼마나 성능을 향상시킬 수 있을까 고민을 해봤다.
빌드할 때 file io 를 줄이고, jvm 구동시간을 줄이면 어떨까 하는 생각으로 시도해보았다.

램디스크를 쓰면, 일반 하드디스크를 쓰는 것에 비해서 성능이 20배이상 좋다는 블로그 (http://forums.bukkit.org/threads/harddrive-vs-ramdisk-vs-tmpfs-benchmark.2710/) 와  10분 걸렸던 빌드가 5분이면 되었다는 블로그(어딘지 못찾고 있음)을 보았다.

10초 내 외의  빌드 시간이 짧은 프로젝트들이 수백 개가 있는 상황에서 램디스크를 활용하면 속도가 향상될지 테스트해보았따.

본론

리눅스에서 RAM 디스크를 사용하는 방법이 두가지이다. ram 디스크과 tmpfs 이다.

1. 램디스크 이용하기 (ramdisk)

/dev/ram* 을 이용해서  9M짜리 램디스크 잡아본다. (9216 = 9*1024M)

]# mkfs -t ext3 -q /dev/ram1 9216
]# mkdir -p /ramdisk
]# mount /dev/ram1 /ramdisk
]# df -H | grep ramdisk

]# df -H
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sda1               11G   3.5G   7.0G  34% /
/dev/sda3              278G   2.7G   261G   1% /home
tmpfs                  6.3G      0   6.3G   0% /dev/shm
/dev/ram1              8.2M   1.2M   6.7M  15% /ramdisk

영구히 쓰려면, 커널을 수정 하거나 grub 설정을 변경해야 한다. 많이 귀찮은 작업이 있다. 잘못하면 OS 부팅이 안되고, 함부로 리눅스 서버를 리부팅할 수 없는 상황이라 간단하게 mount 방식을 이용했다.

]# mkdir –p /ramfs

]# mount -t ramfs -o size=1G,mode=777 ramfs /ramfs

2. tmpfs 를 이용

tmpfs는 임시적으로 파일을 ram을 이용하는 방식이다. 내가 사용하는 centos 5.3 64비트에는 다행히 tmpfs를 지원한다.

]# grep tmpfs /proc/filesystems
nodev   tmpfs

]# mkdir /tmpfs

]# mount -t tmpfs -o size=1G,mode=777 tmpfs /tmpfs

]# df -H
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sda1               11G   3.5G   7.0G  34% /
/dev/sda3              278G   2.7G   261G   1% /home
tmpfs                  6.3G      0   6.3G   0% /dev/shm
/tmpfs                 1.1G      0   1.1G   0% /tmpfs

3. 비교

빌드에 대한 객관성을 유지하기 위해서 캐쉬가 된 부분을 모두 포함한 것이다. ant와 java는 모두 하나의 파일시스템안에 넣었다. 테스트 결과는 다음과 같다.

* 특이한 것은 램에서 돌리는 것이 가장 빠른 것은 아닌 것 같았다. 18초가 나오는 경우도 있었다. 
정확한 이유는 알 수 없지만… (어디선가 바틀렉이 있는것 같다.. 잘 찾아봐야지.)

마치며..

시간을 체크해보 전체 빌드 시간 중 java 컴파일에 해당되는 시간은 상당히 적었다. 연동이나 ivy 연동부분이나 javascript 작업등으로 인해서 길었던 부분이 있었다. 따라서 file io 이슈나 java 시작 시간은 큰 문제가 아니다. 오히려 컴파일 이슈가 큰 녀석이나 해당되는 것 같았다.

확실히 몇 분 단위의 빌드시간이 되어야 RAM 디스크를 이용 하는게 나을 것 같다. 빌드시간이 10초 내외의 수백개의 프로젝트를 빌드할 때는 병렬처리 및 클러스터링 빌드 방식이 더 나은 것 같다. 

나의 서버의 현재 메모리는 시스템적으로 돌아가는 프로세스만 동작 중이다. 그래서 펑펑 놀고 있는 서버이다.

top명령으로 보았을 때, 정보를 보면 약간 이상하다. 전체 메모리 2G에 사용된 (used) 메모리 1.2G이다.  결국 8G 의 free 메모리만 있다. buffers와 cached 메모리에 많은 메모리가 할당되어 있다.

그 이유는 리눅스 커널에서는 프로세스가 반납한 메모리를 바로 free로 돌리지 않는다.

Cached memory는 실행중인 프로그램이 메모리가 필요하다면 바로 대체될 수 있는 free memory인 셈이다. 기존에 실행했던 프로그램이 이 영역을 사용했었고, 또 필요하면 이 영역을 준다고 하면 될 것 같다.

buffers 메모리는 data structure, chunk의 개념이 들어가 있는 메모리인데 반해 cached는 패킷 단위의 메모리 로 보면 된다.

리눅스 커널은 ram에 대해서 buffers, cached, free 이렇게 3단계로 구분해서 메모리를 구분하고 있다.

top 명령어를 통해서 본 메모리를 본다.

VIRT는 프로세스가 전에 사용했던 가상 메모리의 전체 크기를 말한다. code, data, shared library 등을 포함한다. top 명령어는 각 프로세스의 /proc/#pid/state 의 VmSize 의 내용을 가지고 이 정보를 보여준다. swap + res 영역을 더한 값이다. 이 값이 크면, 얼마나 많은 메모리가 접근하고 있는지를 알 수 있는 지표가 된다.

RES는 프로세스가 사용중인 RAM 에 올라간 물리 메모리 (swap 제외) 를 말한다.

SHR는 프로세스가 사용중인 공유 메모리의 합이다.

나머지 정보는 man top 을 통해서 볼 수 있다.