지극히 개인적인 이야기

1. Swap 영역
메모리 구조와 Swap 영역
스왑 공간은 가상 메모리 시스템이 paging process 에 사용하도록 예약된 고속의 기억장치이고, 실제 메모리는 시스템의 유한한 자원.

메모리가 process로 가득 차있는 상태에서 새로운 프로세스가 시작하기 위해 실제 메모리를 사용하겠다는 요구가 높아지면 프로세스의 일부가 디스크 상의 swap  공간으로 옮겨지고, 기존 프로세스가 종료하여 실제 메모리를 사용하겠다는 요구가 낮아지면 프로세스의 일부가 swap 영역에서 메모리로 다시 옮겨진다.

물리적인 메모리(Physical memory)
시스템에 설치된 RAM(Random Access Memory)로 시스템이 기동될때 콘솔에 이 메모리의 크기가 나타남. 문제는 이 메모리의 전부가 프로세스를 위해서 존재하는 것이 아니며, 커널과 OS data structure 에 사용되고 남은 메모리가 사용가능한 메모리로서 paging 을 위해  시스템에서 사용.
일부 프로그램의 경우에는 해당 메모리를 paging 불가능하도록 lock 상태로 만들 수 있다. 보통 DB 와 같은 다중 사용자에 의한 메모리 수정이 일어나느 프로그램의 경우 이렇게 lock을 걸 수 있다.
※ 모든 가용 메모리 영역이 lock 이 걸린다면, 시스템 자체가 deadlock 상태로 빠질 수 있기 때문에 unlockable 메모리가 필요하다.

스왑 영역의 역할
수많은 프로세스들로 인해서 메모리에 발생하는 부하를 줄여주기 위한 것.
시스템의 메모리 상에서 수행중인 프로세스들로 인해 free 메모리의 수준이 어떤 임계값 이하로 떨어지게 되면, 메모리상에서 수행중이던 특정 프로세스나 프로세스의 일부가 새롭게 메모리로 읽어 들여져서 수행되려고 하는 프로세스를 위해 메모리에서 디스크상의 swap 영역으로 옮겨져 free 메모리 영역을 확보해 주는 것,

메모리 구조와 swap 영역
swap 영역의 작동 및 절차
프로세스는 자신이 수행되는 시점에 스왑 영역에 자신이 옮겨질 수 있는 양 만큼은 미리 예약해둠. 이는 실제 메모리에서 예약된 메모리 만큼은 사용할 수 없음을 의미.

스왑 영역의 종류
Primary Swap
시스템이 부팅할때 최소한 하나의 사용 가능한 device swap이 있어야하는데 이것을 일반적으로 primary swap 영역이라고 하며, pseudo swap 을 사용할 수 있다면 꼭 필요한 것은 아니나 사용하기를 권장함. 기본적으로 root filesystem과 같은 디스크 상에 위치하며, 설정 파일인 /stand/system 에 primary swap 에 대한 정보를 담고 있음

Secondary Swap
Primary Swap 에 추가하여 사용되는 장치 또는 파일 시스템 swap을 secondary swap 이라고 하는데, secondary swap 으로 device swap 을 사용한다면 더 나은 성능을 위하여 root 디스크가 아닌 다른 디스크에 할당하는 것이 좋음.
※ 파일 시스템 스왑은 항상 secondary swap 으로만 사용이 가능

스왑 영역의 종류
Device Swap
디스크를 구성할때 최초로 할당된느 swap 영역, dump 영역과 함께 구성하는 것도 가능. NFS등에서 사용하는 클라이언트와 같은 원격 시스템에서 사용할 수 없고, 오직 local 시스템에서만 사용이 가능한 영역.
논리 볼륨이나 디스크 파티션에 직접적으로 swap 만을 위한 다량의 IO가 일어날 수 있기 때문에 다른 swap 영역에 비해서 access 속도가 빠른 장점.

File System Swap
시스템에서 현재 사용하고 있는 device swap 보다 더 많은 swap 영역을 필요로 할때 이런 file system swap 을 설정. file system swap 의 경우 시스템에 더 많은 양의 프로세스 수행을 필요하기 때문에 영구 사용에는 적합하지 않음. 원격에도 존재가 가능하며, cluster 의 클라이언트로 구성되어 있는 시스템의 경우 원격 file system swap 을 사용할 수 있음.

pseudo swap
새로운 프로세스를 수행하기에는 남아있는 스왑영역의 크기가 작아서 수행이 불가능할경우 물리적으로 존재하지 않는 스왑 영역을 논리적으로 OS 가 인식하도록 만들어진 가상의 swap 영역이라고 할 수 있음.
메모리에서 swap devices 에 의해 지원된느 것보다 많은 양의 프로세스를 수행 가능하도록 하구이해서 등장. 크기는 시스템의 메모리의 크기에 따라 달라지지만, 일반적으로 메모리 크기의 7/8(87%)정도가 적당함. 커널 파라미터 중 swapmem_on = 1로 설정하면서 활성화된다.
※ sam, sysdef 를 이용해서 확인 가능.

2. Swap 영역의 관리
스왑 영역의 상태보기
swapinfo 명령이란?
어느 정도의 swap 이 사용중, 예약되어 있는지 swap 과 관련한 중요한 정보를 관리자에게 보여준다. 또한 device swap 이나 file system swap 에 대한 정보도 포함되어 있음.

스왑 영역의 설정, 해제
swapon

lvlnboot(lvrmboot)
LVM을 사용할 경우 현재 어떤 볼륨이 primary swap영역으로 사용하고 있는지 볼수 있게함.
primary 스왑 변경
single user mode 변경.

/etc/fstab
시스템이 부팅할때 설정해 놓은 swap 영역이 사용 가능하도록 하게 하려면 /etc/fstab 파일에 swap 영역을 정의

스왑 영역의 설정, 해제
/etc/fstab 각 필드의 의미는 무엇일까?
block device / 시스템에서 사용할 특정한 block 파일명을 기록하여 주는 곳
directory / 마운트된 파일 시스템의 이름을 기록하는 곳. device swap으로 사용할 경우 이 필드에 ...을 기록하여 주면 됨.
type / swap이나 swapfs 또는 ignore가 들어갈 수 있음. 다른 값이 들어갈 경우는 마운트하여 파일 시스템으로 사용하는 경우. 필드의 내용이 swap일 경우에는 directory, backup-frequency, pass_number 가 모두 무시되고 필드의 내용이 swapfs 일 경우에는 block device, backup-frequency, pass_number 가 모두 무시
options / 세번째 필드가 swap이거나 swapfs 인 경우 swapon 명령의 옵션을 기록.
backup-frequency / swap 영역은 백업이 필요없는 영역이므로 현재는 사용하지 않음.
pass_number / swap이나 swapfs 의 경우에는 미사용. fsck 에 의해서 파일 시스템 체크의 우선순위를 결정

3. Dump란?
Dump 영역이란?
Crash Dump 는 시스템이 비정상적으로 종료될 경우 시스템의 물리적인 메모리에 load 되어 수행중이던 page들을 이미지의 형태로 디스크의 특정 영역에 추출해내는 것임. 이 정보는 차후 비전상 종료의 원인 분석/ 크래시 발생 시점의 작업 내용을 복구하는 중요한 근거 자료로 사용가능.

상기의 파일들은 시스템 크래시 이후 dump 영역에 남겨진 내용을 savecore 프로세스가 crash dump 로 생성된 파일을 보여준다.

Dump 영역의 특징
특별히 dump 영역을 설정하지 않을 경우 기본적으로 primary swap 영역을 dump 영역과 공유하게 됨.
crash dump는 평상시에는 전혀 사용하지 않으나 시스템에 이상이 발생하여 auto reboot 할 경우 작동하는 기능. 시스템이 처음 기동하면 crash dump가 이루어지는 시점이 시스템이 부티에 필요한 swap 영역을 사용하려는 시점보다 앞에 있기 때문에 시스템의 디스크 자원이 충분히 여유롭지 않다면 이 방법을 사용하는 것이 좋음. (빠른 부팅, dump 이미지를 보호하는 차원에서 적절한 방법은 아님)

dump 영역을 시스템에서 여러 개의 다른 곳에 구성할 수 있음.
일반적인 루트 디스크의 경우 디스크의 개수가 많지 않기 때문에 dump 영역을 여러곳으로 분산시켜서 구성하지는 않음. 그러나, 디스크 자원이 충분할  경우 이러한 dump 영역을 여러개의 다른 물리적인 디스크로 분산하여 구성. (분산 구성시 crash 발생할 경우 더 빠른 부팅 시간을 보장함)

dump 영역으로 사용할 논리 볼륨이나 디스크의 파티션이 필요함.
시스템의 dump 영역은 일반 파일들을 저장하는 영역을 사용하지 못함. 별도의 논리 볼륨이나 파티션을 따로 작성해야하는데 이때 해당 파티션은 contiguous, non bad block relocation^[각주:1] 특성을 가져야함.

swap 영역과 dump 영역은 공유가 가능하지만 디스크의 free 영역이 충분하다면 별도의 dump 영역을 설정하여 주는 것이 좋음.
시스템의 재부팅시 fast booting 과 swap 영역과 공유하고 있는 곳에서 crash dump 된 데이터가 시스템이 rebooting 하여 파일 시스템으로 옮겨지기 전에 swap 영역을 사용하게 되면서 데이터의 손실이 발생할 수 있게 될 수도 있기 때문

Dump Device 영역의 크기
시스템의 덩치가 커지면서 메모리의 크기도 커지게 돼고 이렇게 돼면서 실제로 problem debugging 해 필요한 시간이 많이 걸리게 되었는데 이에 따라서 실제로 디버깅에 필요한 부분만을 별도로 추출하는 방식이 도입

full dump
물리적 메모리에 모든 내용을 dump 하는 경우. crash 원인 분석에 모든 내용이 필요하지 않음. 최근에는 지양하는 방식이며, 이 방식으로 덤프를 받을 경우 dump device 의 크기는 물리적인 메모리 크기 + 10MB 정도가 필요함.

selective dump
메모리 내용을 dump 하거나 crash dump 저장 시간을 줄이기 위해서 debugging 필요 부분을 dump 하는 방법. Transfer of Control (TOC)나 시스템 hanging 시에도 기본적으로 적용되는 방법. 해당 방식이 수행 불가능할 경우에는 full dump 시도. 필요한 덤프 영역의 크기는 물리 메모리 크기 * 0.24 + 10MB 또는 시스템의 부하가 많을때 crashconf -v로 확인한 결과 값을 기준으로 잡으면 된다.

유용한 정보를 손실없이 빠르고 적은 공간에서 저장. dump device 구성을 위해서 커널을 재구성하거나 시스템 리부팅 불필요. dedicated dump device로 파일 시스템에 카피하지 않고 dump를 debug 할 수 있음.
no dump
덤프를 사용하지 않고 시스템의 빠른 부팅을 보장하는 방식. 원인 분석이 크래시 전의 로그를 통해서 분석하는 것에 그침.

Dump 영역의 설정

Dump device 영역의 크기
필요한 덤프 영역의 크기를 측정하는 방법. selective dump 를 이용하는 경우 상황에 따라서 관리자가 덤프 영역의 크기를 조절해야하기 때문에 필요한 크기를 측정하는 방법을 알 필요가 있음.

unix cmd 를 이용한 dump 영역 설정.
시스템의 총 메모리가 16GB라고 가정하고 비정상 종료시 uptime 을 최대한 보장하면서 비정상 종료를 유발한 원인을 분석할 필요가 있을 경우.

상세 과정

dump 영역의 설정 2
커널상에 dump 영역 정의하기 (by sam)
 시스템을 사용중이거나 부트 프로세스 단계에서 dump 가 필요한 경우 커널에 dump 영역을 정의. SAM을 이용하여 dump 영역을 정의하는 방법과 Unix 명령어를 이용하여 정의하는 방법. SAM의 경우에는 굉장히 단순하게 설정하는 것이 가능.
(단 SAM의 list 상의 dump device 순서는 우선 순위가 역순으로 되어 있다는 것임. 즉, list 상의 마지막 device 가 최초로 사용하는 dump device 임)

커널상의 dump 영역 정의 (by unix cmd)

시스템 가동중에 dump 영역 정의
단, 주의할 것은 crashconf 명령을 사용하여 추가한 dump 영역중 하나의 dump 만큼은 구성 정보에서 바로 삭제가 되지 않고 반드시 rebooting 해야 한다는 것임.

boot time utility인 savecrash 는 reboot시 dump device 에서 file system 으로 이미지를 카피할때 데이터를 압축혹은 비압축하여 구성함. 데이터를 압축하면 시스템 백업이 더 올래 걸림.
만약 파일 시스템 공간이 부족하다면 데이터를 압축하되 이것이 어려운 경우에는 OS에서 따로 지원되는 debugger로 dump device 에서 직접 dump를 분석하는 것도 가능함. libcrash 를 사용하여 커널 디버거인 adb와 q4를 이용해서 dump device 에서 바로 데이터를 읽는 것도 가능함.

일반적으로 시스템 관리자가 dump 데이터 분석하는 것은 어려운 일이기 때문에 이런 방법보다는 dump 영역을 충분히 할당하는 것이 일반적인 해결책이다.

/etc/rc.config.d/savecrash 에서 내용을 확인할 수 있다.

crashconf
시스템의 부팅이나 running 시에 만들어진 dump device의 정의를 바꾸거나 추가하는데 사용하는 명령어

더보기

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.