글 1:
리눅스 커널에는 여러 종류의 I/O 스케줄러가 있어서
그 중에 하나를 골라쓸 수 있게 되어있다.

그 중에 noop 이라는
스케줄러가 있는데….
단순한 FIFO 큐로 이루어진 I/O 스케줄러이다.
이 스케줄러의 특성상
SSD나 파일 기반 디스크
이미지일 경우 최고의 퍼포먼스를 내며,
하드웨어 기반의 RAID 사용시 컨트롤러 자체 I/O 스케줄러가 있을 경우 속도에 이득이
있다.

다음을 부트 로더의 커널 항목에 추가한다.
(grub일 경우
/boot/grub/menu.lst)

elevator=noop

참고
noop 스케줄러가
SSD나 파일 기반 디스크 이미지에 최고의 퍼포먼스를 내는 이유는
SSD나 파일 기반 디스크 이미지는 메모리처럼 주소 기반이기
때문이다.
(파일 기반 디스크 이미지의 경우 이미지가 들어있는 하드디스크의 영향을 받는다.)

p.s
일반 하드디스크일 경우에는 현재 cfq의 포포먼스가 가장 좋다고 알려져 있다.

글 2:

본론으로 들가기 전에 테스트 사양
SSD : SAMSUNG MMCRE64G5MXP-0VB, VBM1901Q
O/S : centos5
64비트

한동안 SSD 노래를 부르고 지냈다. 집에서 랩터구형을 쓰고 있는 상황에서 하드 속도 향상으로 인한 무지막지한 쾌적한
컴퓨팅을 꿈꾸며 모 일회용 렌즈 CF 처럼 "하고 싶은 일들이 많아졌어요~" 라던지 "자신감이 생겼어요~" 라던지 "하드를 SSD로 바꿨더니
개발에 전념할 수 있을꺼 같아요~" 라던지 비싸디 비싼 가격에 침만 질질질 흘리고 있었다.

그러던 중 새롭게 들어가는 프로젝트
서버에 SSD 가 세팅이 되어졌다. 최고의~ 속도를 느껴 볼 수 있을꺼라는 생각에 이것저것 테스트를 하는데.

역시나!!! 수십만개
파일 카운팅 검색 등에서 탁월한 성능을 발휘하는것 아닌가!!! 점점 SSD 뽐뿌가 치닫고 프로젝트도 어느덧 막판으로
들어섰는데…

후반에 갈수록 순간 엄청난 딜레이가 걸리는 경우가 발생하였다. 텔넷 접속이 버겹고 기본적인 명령어조차 먹히지 않는
경우가 발생하였다. 시스템을 조사하는데 특별하게 들어오는 트래픽도 나가는 트래픽도 그렇다고 뭐가 바쁘게 계산하거나 루프 도는것도 그냥
wating 이 걸리고 평균 로드율이 급상승을해 내려올 생각을 하지 않는 것이다.

겨우 겨우 명령어들 기다리면서 찾아보니 프로젝트상
다량의 데이터를 받아오는 시점이 있었는데 그때에 모든 기능들이 멈칫!! SSD의 문제점중 하나인 프리징! 막상 당해보니 이건 어찌 넘길 수 있는
문제가 아닌거 같다. 단순 10~100kb 사이의 데이터들을 자잘하게 받는 도중에 생겨서 대안도 없고 하드웨어적 문제라 개선할 수 있는 방법도
그렇다고 하나씩 받자니 갯수가 많아 시간이 걸릴꺼 생각하면 답이 안나오고…

웹을 뒤졌다. 기존에 서버에서 SSD를 사용하는
사람들이 많기에 관련 정보가 있는지. 힘들게 찾고 있는데 삼성쪽은 홈페이지던 뭐던 그닥 정보가 없고 뒤적뒤적 겨우 나오는
정보는

리눅스에서 SSD 최적화
설정

OS 업그레이드 커널 2.6.28(페도라 11, 우분투 9.04) 에서 SSD를 인식한다고 한다. 거기에 하드 파일
포멧도 변경해야 되고 EXT3, EXT4 로…

가장 좋은건 RAID 0 으로 엮어 버리는 방법도 있다고 한다. 기존 운영체제는
디스크 방식에 최적화 되어있는지라 SSD와는 사뭇 맞지 않는다고 할 수 있다.

결국 다중 쓰기를 최대한으로 줄였다. 기존 동시쓰기
데몬의 수를 절반으로 줄여서 엄청난 프리징은 피함. 그래도 제법 프리징 걸림.

딱히 대책이 없구나 쓰기에 대해서는 이놈… 업글을
하던지 두갤 달던지 쓰기용으로 디스크방식 하드를 달던지. 가장 편한건 디스크 방식 하드인가… 흠…

글 3:
SSD를 사용하기 전에:

SSD는 "HDD와는 다르다! HDD와는!" 이라는 마인드부터 갖추어야 한다.

그래야 아래에 등장하는 귀찮은 설정들을 해낼 수 있다.

OCZ 포럼에 관련 글이 있다. 보러가기 (영어 주의)

우분투 9.10에 실제로 적용해 본 사람의 팁들도 있다. 보러가기 (영어 주의)

주의:

SSD에 OS를 설치하는 상황이라면 일부 지침은 설치 전 복구모드로 들어가서 실행해야 한다.

특히 Alignment 는 반드시 복구모드에서 실행하고 파티션 설정도 미리 해놓기 바란다.

1.

커널 2.6.33 부터 Windows 7 처럼 커널 수준의 자동 TRIM을 지원한다.1

물론 당연히 SSD가 TRIM을 지원해야 한다.

2.

커널 2.6.28 부터 제한적인 TRIM이 지원되기 시작했다.2

hdparm 이나 wiper.sh 같은 것으로 수동 TRIM을 실행해야 한다.

모르면 닥치고 구글링.

3.

SSD Alignment를 해야 한다. 그래야 최고의 퍼포먼스를 낼 수 있다.

SSD Alignment는 보통 하나의 섹터 단위를 512 바이트로 잡는데, 헤더를 32, 실린더를 32로 잡으면 된다.

또한 ext 계열의 파일 시스템일 경우 mkfs 할 때 Alignment를 해줘야 한다.

ext2/ext3/ext4의 mkfs alignment 는 OCZ과 SanDisk에서 128k align을 권장하고 있다.

4.

NAND 플래시 셀 하나의 수명은 의외로 매우 짧은 수준이기 때문에34
쓰기를 최대한 억제해야 한다.

따라서 Windows에서 램드라이브를 만들어 사용하듯이 일부 영역을 tmpfs로 옮겨서 마운트해야 한다.

일반적으로 /tmp, /var/log, /var/tmp 를 tmpfs로 물린다.

파폭의 캐시 디렉토리도 tmpfs에 물려있는 경로로 설정해야 한다.

(이것은 꼭 SSD가 아니라도 적용하면 속도가 빨라진다고 한다. 윈도우의 경우에는 이미 수많은 설명이 있으니 닥치고 구글링.)

5.

이번에는 커널 스케줄러도 바꿔야 한다.

언젠가 올렸던 글에서도 언급했지만 noop 이 좋다. deadline 또한 좋다고 한다. (I/O가 현저하게 줄어든다.)

(근데 장기적으로 스케줄러를 하나로 통합한다는 말이 있어서 어쩔까나…)

6.

sysctl 설정 값도 바꾸면 당연히 좋다. (특히 swap 죽이기 용)

7.

smartmontools, hdparm 같이 유용한 툴들을 설치한다.

필요할 때마다 상태를 모니터링 하고 설정을 확인하는데 좋다.

8.

btrfs 라는 게 있는데 (Oracle 에서 만듬)

아직 개발중인 파일 시스템이라지만 SSD에 최적화된 옵션이 있다고 한다.

우분투 10.10부터 정식 지원 예정. 단 아직은 btrfs에 부팅 파티션을 설정할 수 없다.

9.

squashfs 라는게 있다.

설명하기 귀찮으니 검색은 알아서.

(이것은 꼭 SSD가 아니라도 적용하면 속도가 빨라진다고 한다.)

적용시 특히 주의해야 한다. 주기적으로 변경된 것을 반영하고 쓰기 캐시를 지우는 작업을 해야 되는데

잘못하면 리눅스가 죽는다.

  1. 우분투
    10.10이 해당된다.
  2. 우분투
    9.10과 10.04 LTS 가 해당된다.
  3. SLC는
    최대 10만번, MLC는 최대 만번의 쓰기가 가능하다.
  4. 물론
    NOR칩은 NAND칩과 비교할 수 없을 정도로 수명과 내구성이 길지만 지상 최대의 진리인 돈 문제(무지 비싸다)로 인하여 흑역사가 되고
    말았다.
리눅스에서 ssd 빠르게 쓰기

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다