한빛출판네트워크

저자: 롭 플리켄저(Rob Flickenger), 역 서성용

최소 한 개의 (E)IDE 하드 드라이브를 이용하여 인텔 리눅스 시스템을 운영하고 있는가?

하드디스크 I/O 성능을 즉시 두 배로 늘려줄 수 있는 마술같은 명령이 있다면 멋지지 않을까? 그렇지 않고 현재의 전송률을 6~10배 정도 빠르게 보여줄 수 있다면?

잔뜩 꾸민 리눅스 박스가 어떤 성능을 보여줄지 궁금해 해본 적은 없는가?

hdparm(8)을 간과하지 말자. 전혀 들어본 적이 없더라도 걱정할 필요는 없다. 내가 얘기해본 사람들 대부분도 그랬다. 하지만 당신이 IDE/리눅스 시스템을 운영하고 있다면(많은 사람들이 그렇듯이), hdparm(8)을 사용하지 않고 지금까지 어떻게 버텨왔는지 궁금할 것이다. 나도 그랬다.

그래서 어쨌다는 것인가?

이제 여러분은 다중 PIO 모드와 DMA, 가죽 시트 옵션과 특별한 크롬 도금을 입힌 최신 컨트롤러 칩셋과 함께 최신 UltraATA/66 EIDE 드라이브를 얻었다. 그렇지만 실제로 시스템이 이와 같은 멋진 기능을 이용하고 있는가? hdparm(8) 명령은 드라이브가 어떻게 동작하고 있는지 알려줄 뿐 아니라 마음에 들 때까지 미세한 것도 조정할 수 있게 해준다.

너무 흥분하기 전에, 특정 환경에서 이와 같은 명령들이 예상하지 못한 데이터 손상을 야기시킬 수도 있음을 지적해두는 것이 좋겠다. 최소한 작업을 진행하기 전에 리눅스 박스를 백업하고 단일 유저 모드로 전환하는 것이 좋을 것이다.

보통 책임을 회피하는 방법으로 만약 최신 하드웨어를 사용하고 있다면(다시 말해, 여러분이 사용하고 있는 드라이브와 컨트롤러와 마더보드가 최근 2,3년 이내에 생산된 것), 위험성은 매우 낮아진다는 점을 지적해두고 싶다. 필자는 다양한 하드웨어 설정을 갖는 여러 박스에서 이 명령들을 사용해왔지만, 내가 본 가장 최악의 상황은 가끔씩 프로그램 실행중 시스템의 오동작이나 프로그램 오류 등에 의해 실행이 중단되는 것으로 어떤 입력에 대해서도 반응하지 않으며, 복구하려면 전원을 껐다가 다시 켜야 하는 행(hang)이었는데, 리부팅하면 자료에는 문제가 없었다. 그리고 개인적인 불행에 대해 나와 세상에 대해 어떤 원망을 하든지 상관없이, 우리 모두는 당신의 박스가 잘 있는 것에 대한 궁극적인 책임을 가진 사람이 누구인지 알고 있다. 그 궁극적 책임은 바로 당신에게 있다.

자, 그렇다면… 내가 아직 여러분을 충분히 겁주지 못했다면 이렇게 해보자(루트로, 단일 유저 모드에서 하는게 좋음).

hdparm -Tt /dev/hda

그러면 아래과 같은 메시지를 보게 될 것이다.

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.34 seconds =95.52 MB/sec
 Timing buffered disk reads:  64 MB in 17.86 seconds = 3.58 MB/sec

이것은 우리에게 무엇을 알려주는가? -T는 캐시 시스템 검사를 의미한다(다시 말해 메모리, CPU, 버퍼 캐시). -t는 제시한 디스크에 대해 캐시에서 데이터를 읽어오지 않을 경우의 통계를 출력하는 것을 의미한다. 단일 유저 모드에서 두 가지를 한꺼번에 한 줄에서 여러 번 실행해주면 디스크 I/O 시스템의 성능을 알 수 있을 것이다. (이것들은 PII/350 / 128M 램 / 신형의 EIDE 하드디스크에서 얻은 실제 수치로 여러분이 얻게 될 수치는 이와 똑같지는 않을 것이다.)

값들이 변한다고 하더라도 3.58MB/sec라는 수치는 위의 하드웨어에서는 형편없다. 필자는 하드디스크의 광고에서 대략 초당 66MB 라고 말하는 것을 본 것 같다!!?!? 이것이 무엇을 의미하는 것일까?

그렇다면, 리눅스가 드라이브를 어떻게 어드레싱하는지에 대해 자세히 살펴보도록 하자.

hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 1870/255/63, sectors = 30043440, start = 0

이것들이 기본값이다. 안전하기는 하지만 반드시 최적은 아니다. 16비트 모드에 대한 것은 어떤가? 나는 386과 함께 사라져버렸다고 생각했는데! 그리고 다른 옵션들 대부분이 꺼져 있는 이유는 무엇인가?

일반적으로 능숙하면서도 가능한 한 안전한 방법으로 자체적으로 설치하는 것이 좋다. 위에서 언급한 셋팅 방법들은 어느 하드웨어에서든지 가상으로 작동하게 되어있다. 그렇지만 우리는 8년 짜리, 16비트 멀티 IO 카드를 다룰 것이다. 따라서 이제부터는 흥미로운 옵션에 대해 살펴보도록 하겠다.

• multicount: multiple sector count의 약자이다. 이것은 한번의 I/O 인터럽트에 디스크에서 얼마나 많은 섹터가 읽혀질 수 있는지를 제어한다. 대부분의 모든 최근의 IDE 드라이브들은 이것을 지원한다. 맨 페이지에는 다음과 같이 나와 있다.




이 기능이 활성화되면 디스크 I/O에 대한 운영체제 오버헤드를 보통 30-50% 감소시킨다. 이것은 많은 시스템에서 5%에서 50% 가량의 향상된 데이터 전송률을 제공한다.

• I/O 지원: 이것이야 말로 중요하다. 이 플래그는 데이터가 PCI 버스에서 컨트롤러로 통과하는 방법을 제어한다. 거의 모든 모던 컨트롤러 칩셋들은 3 또는 32비트 모드 w/sync를 지원한다. 어떤 모델은 32비트 async까지도 지원한다. 이것을 켜주면 거의 두 배정도 전송률을 증가시킬 수 있을 것이다.
• unmaskirq: 이것을 켜는 것은 리눅스가 한 디스크 인터럽트를 처리할 때 다른 인터럽트를 언마스크(unmask)하도록 허용할 것이다. 이것이 의미하는 것은 무엇인가? 요청된 데이터를 디스크가 리턴하기를 기다리는 동안, 리눅스가 다른 인터럽트와 관련된 작업(예를 들어 네트워크 트래픽)을 처리하도록 한다. 그것은 전체적인 시스템 반응(response) 시간을 향상시켜 주지만 주의해야 한다. 모든 하드웨어 설정이 그것을 처리할 수 있도록 되어 있지 않기 때문이다. 자세한 것은 맨 페이지를 참조하라.
• using_dma: DMA는 위험할 수도 있다. 만약 컨트롤러와 드라이브 모두가 DMA 모드를 사용하게 할 수 있다면 그렇게 하라. 하지만 필자는 이 옵션을 한 대 이상의 머신에서 사용할 경우 자주 행(hang)이 되는 것을 경험했다. 다시 말하지만, 맨페이지를 참조하라(그리고 다음 페이지에 있는 예제들도)!

Turbocharged

단일 모드로 전환했으므로 몇 가지 터보 설정을 해보자.

hdparm -c3 -m16 /dev/had

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 multcount    =  16 (on)
 I/O support  =  3 (32-bit w/sync)

훌륭하다! 32 비트가 좋아보인다. 그리고 일부 다중-리드도 작동할 것이다. 벤치마크를 다시 실행해보자.

hdparm -tT /dev/had

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.41 seconds =90.78 MB/sec
 Timing buffered disk reads:  64 MB in  9.84 seconds = 6.50 MB/sec

와우! 큰 노력을 하지 않고도 디스크 전송률이 거의 두 배가 되었다! 믿을 수 없다.

이것 말고도 더 많은 것들이 있다. 아직까지 인터럽트를 언마스킹하거나, DMA를 사용하거나, decent PIO 모드 조차도 사용하지 않았기 때문이다. 물론 이것들을 활성화하면 위험해진다. (왜 항상 자유와 안전사이에서 거래가 이루어져야 하는가?) 맨 페이지는 Multiword DMA mode2를 시도하는 것에 대해 다음과 같이 언급하고 있다.

hdparm -X34 -d1 -u1 /dev/had

안타깝게도 이것은 이 특정 박스에서 지원되지 않는 것으로 보인다(자바 애플리케이션을 실행하는 NT 박스처럼 행됨). 따라서 리부팅한 후에 (다시 싱글유저 모드로), 다음과 같이 해주었다.

hdparm -X66 -d1 -u1 -m16 -c3 /dev/had

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 setting unmaskirq to 1 (on)
 setting using_dma to 1 (on)
 setting xfermode to 66 (UltraDMA mode2)
 multcount    = 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)

그리고 난 후 점검해보았다.

hdparm -tT /dev/had

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.43 seconds =89.51 MB/sec
 Timing buffered disk reads:  64 MB in  3.18 seconds =20.13 MB/sec

20.13 MB/sec. 우리가 시작했던 3.58로부터 멀리서 울음소리가 들려온다.

그런데, 우리가 어떻게 -m16과 -c3 스위치를 다시 시정했는지 주목해보자. 이것은 리부팅할 때 hdparm 셋팅을 기억하지 못했기 때문에 가능했다. 일단 시스템이 안정적인 것을 확인했다면 위의 줄을 /etc/rc.d/* 스크립트에 확실히 추가해야 한다(fsck 가 동작한 후에 추가하는 것이 좋다. 컨트롤러를 이상한(flaky) 모드에 두고 광범위한 파일시스템 검사를 실행하는 것은 거대한 양의 엔트로피를 발생시키기에는 좋은 방법이지만 시스템을 관리하는 방법은 아니다.)

이제 벤치마크를 몇 번 더 실행한 후, 멀티유저 모드로 리부팅해서 X를 띄운다. 넷스케이 프를 로딩하고 자리를 뜨지 않도록 한다.

결론

본 기사는 "노련한" 리눅스 베테랑들 회피하는 재밌는 이야기들 중에 하나에 지나지 않는다. 그리고 hdparm을 사용하는 것이 완전히 위험이 없는 것은 아니지만 분명 연구해볼 가치는 있다.

단지 성능향상만 관련있는 것은 아니다. hdparm은 다양한 절전 모드도 설정할 수 있다. 이에 대해서는 hdparm(8)을 참조하기 바란다.

이 멋진 유틸리티와 함께 참여해준 마크 로드(Mark Lord)에게 매우 감사하게 생각한다. 만약 당신의 특정 배포판이 hdparm을 포함하고 있지 않다면(대개 /sbin 이나 /usr/sbin에 있다), http://metalab.unc.edu/pub/Linux/system/hardware/에서 소스를 구할 수 있다.

해피 해킹!

롭 플리켄저(Rob Flickenger)는 오라일리 네트워크 시스템 관리자이다.