Home | 문태준 | 시스템어드민 메일링 | Sys Admin 세미나
Skip to end of metadata
Go to start of metadata

Tuning Red Hat Enterprise Linux on IBM eserver xSeries Servers

예전에 제가 봤던 자료는 2004년판인데 2005년판 업그레이드가 되었음. 아래 자료는 예전 자료 기준

http://www.redbooks.ibm.com/abstracts/REDP3861.html

9장 Tuning the file system

하드웨어 고려사항

disk i/o 가 중요한 서버 : 파일, 프린터 서버.

disk i/o 가 덜 중요한 서버 : 이메일(네트워킹 중요), 웹서버(네트워크, 메모리 중요)

디스크 기술 선택 : EIDE, SCSI, SATA, iSCSI, Fiber Channel

디스크 숫자 : 최적의 디스크 서브시스템은 서비스 I/O 요청을 처리할 수 있는 read-write 헤드의 숫자를 최대화하는 것에 달려있다.

next3 의 특성

가용성

데이타 정합성 : data=journal . 파일 데이타와 메타데이타 모두 저널링함

속도 : data=writeback . 동시에 쓰기 작업이 많은 경우 유용함

유연성 : ext 에서 포맷없이 업그레이드 가능

기타 저널링 파일 시스템 : reiser fs, jfs, xfs

커널에서 파일 시스템 튜닝

Access time update : noatime 옵션은 inode access times 기록을 하지 않는다.

elevator 알고리즘 튜닝 : throughput 과 latency 간의 조정. 2.4 커널에서는 elvtune 을 이용하며 2.6 커널에서는 /sys/block 구조를 통해서 처리함. ** read-ahead 와 관련이 있는지는 정확히 모르겠음

ext3 에서 저널링 모드 선택 : data=journal, orderd(default), writeback. writeback 은 시스템 붕괴시 파일에서 오래된 데이타가 보일 수 있다.

bdflush : 가상 메모리 서브시스템 튜닝.

Tagged command queing(TCQ) for SCSI drives : 큐에 있는 동안 i/o 요청에 태그를 매기고 순서를 재정하는 기법. 드라이브 헤드의 위치를 최적화하여 요청을 재정렬하는 방식을 통해 매우 많은 랜덤한 엑세스가 있는 환경에서 i/o 성능향상에 도움이 된다. 이 기술은 최근(question) ide 드라이브에도 확장이 되었으며 ATA TCQ 또는 legacy TCQ 과 SATA II 기술명세에서 Native Command Queuing(NCQ) 가 있다.

블락 크기 : 작은 파일이 많은 경우 작은 블락 크기가 효율적이다. 큰 파일이 많은 경우 블락 크기가 클 경우 성능향상에 도움이 된다. 블락 크기를 재조정하려면 포맷을 해야 한다. 하드웨어 레이드를 사용할 경우 stripe 크기를 고려해야 한다. 일반적인 규칙으로 스트리밍 또는 순차적인 내용은 스트립 크기가 클 경우 유용한데 디스크 헤드의 탐색 시간을 줄여주고 처리량을 향상시킨다. 대신 dbms와 같이 임의의 접근이 많은 경우에는 레코드 크기와 비슷한 스트립 크기가 더 좋다. RHEL의 블락 크기는 1K, 2K, 4K 이다.

파티션 세팅 안내

스왑 파티션

4장 디스크 병목현상

디스크 서비시스템의 성능은 서버 성능에서 가장 중요한 부분중의 하나이며 일반적으로 가장 많이 발생하는 병목현상이다. 그러나 메모리 부족등 다른 요스에 의해 문제가 감추어진다. CPU 사이클이 I/O 작업을 마치기 위해 기다리면서 낭비되는 경우가 "I/O BOUND" 애플리케이션이다.

디스크 병목현상 찾기 (또는 메모리 문제가 숨겨진 경우)

디스크가 느린 경우 메모리 버퍼가 쓰기 데이타(또는 데이타를 읽기 위해 기다리는)로 가득찬다. 쓰기 요청(또는 디스크 큐에서 데이타를 읽기 위해서 기다리고 이는 응답)을 처리할 수 있는 자유 메모리 버퍼가 없어서 모든 요청이 늦어진다. 또는 네트워크 요청을 처리할 수 있는 충분한 메모리 버퍼가 없는 경우와 같이 메모리가 부족하여 동기화하는 disk i/o 가 생겨난다. ???? 번역내용이 좀 이상?? 디스크가 느려서 메모리 버퍼가 꽉 차고???

디스크 , 컨터롤러 활용율(utilization)이 매우 높을 것이다.

대부분 LAN 전송은 disk i/o 처리가 완료된후 진행하기 때문에 매우 긴 응답 시간과 낮은 네트워크 활용률을 발생시킨다.

disk i/o 는 상대적으로 긴 시간이 소요되고 디스크 큐가 꽉 차기 때문에 다음 요청을 처리하기 전에 오랜 시간을 기다려야 해서 CPU는 idle 이거나 낮은 활용율를 보일 것이다.

디스크 인터페이스의 속도와 용량을 살펴보는 것과 다르게 workload 를 이해하는 것이 필요하다. 디스크 접근이 랜덤형태 또는 순차적인가? I/O가 큰가 작은가?

디스크 비교 :

Disk Speed

Latency

Seek time

Total random access time

I/Os per second per disk

Throughput given 8KB I/O

15,000 PM

2.0ms

3.8ms

6.8ms

147

1.15MBps

10,000 RPM

3.0ms

4.9ms

8.9ms

112

900KBps

7,200 RPM

4.2ms

9ms

13.2ms

75

600KBps

Total random access time : Assuming that the handling of the command + data transfer < 1 ms, total random access time = latency + seek time + 1 ms

IOP : Calculated as 1/total random access time

random read/write 는 일반적으로 여러 디스크에 분산시키는 것이 필요하다. SCSI 나 Fibre Channel 의 버스 대역폭은 관계가 덜하다. random access worklaod 를 가지는 규모가 큰 데이타베이스는 여러개의 디스크가 있을 수록 유리하다. 규모가 큰 SMP 서버노 여러개의 디스크가 있을수록 좋다. 70% read, 30% write 인 일반적인 상업적 환경에서 RAID-10 은 RAID-5 보다50-60% 빠르다.

순차적인 작업의 경우 디스크 서브시스템의 버스 대역폭을 압박한다. 최대의 처리량이 필요할 경우 SCSI 버스와 Fibre Channel 컨트롤러의 숫자에 투자를 해야 한다. 어레이에 드라이브 갯수가 비슷할 경우 RAID-10, RAID-0, RAID-5 모두 비슷한 streaming 읽기 및 쓰기 처리량을 보인다.

디스크 병목현상을 분석할 때 접근법이 두가지 있다. 실시간 모니터링은 문제가 발생했을때 진행되어야 한다. 시스템 워크로드가 동적이고 문제가 반복되지 않으면 상관없지만 문제가 반복된다면 중요한 부분이다. Tracing is the collection of performance data over time to dagnose a problem ??

nvmstat : bi, bo 가 중요한 부분

niostat : 매우 많은 파일을 반복적으로 open, read, write, close 하면 성능에 문제가 생긴다. 검색 시간(데이타가 저장되어 있는 정확한 트랙으로 옮기는데 걸리는 시간)이 증가하게 된다. iostat를 통해 실시간으로 i/o 디바이스의 상황을 볼 수 있다. iostat --x 옵션으로 자세한 상황을 볼 수 있다. 중요한 것 몇가지는 다음과 같다.

%util Percentage of CPU consumed by I/O requests

svctm Average time required to complete a request, in milliseconds

await Average amount of time an I/O waited to be served, in milliseconds

avgqu-sz Average queue length

avgrq-sz Average size of request

rrqm/s Number of read requests merged per second that were issued to the device

wrqms Number of write requests merged per second that were issued to the device

Iowait : Time the CPU spends waiting for an I/O operation to occur. High and sustained values most likely indicate an I/O bottleneck.

Average queue length : Amount of outstanding I/O requests. In general, a disk queue of 2 to 3 is optimal; higher values might point toward a disk I/O bottleneck.

Average wait : A measurement of the average time in ms it takes for an I/O request to be serviced. The wait time consists of the actual I/O operation and the time it waited in the I/O queue

Transfers per second : Depicts how many I/O operations per second are performed (reads and writes). The transfers per second metric in conjunction with the kBytes per second value helps you to identify the average transfer size of the system. The average transfer size generally should match with the stripe size used by your disk subsystem.

Blocks read/write per second : This metric depicts the reads and writes per second expressed in blocks of 1024 bytes as of kernel 2.6. Earlier kernels may report different block sizes, from 512 bytes to 4 KB.

Kilobytes per second read/write : Reads and writes from/to the block device in kilobytes represent the amount of actual data transferred to and from the block device.

elevator 알고리즘을 튜닝하면avgrq-sz(average size of request), avgqu-sz(average queue length) 를 볼 수 있다. elevator 튜닝을 통해 지연시간을 줄이면 avgrq-sz 숫자는 내려갈 것이다. 또한 rrqm/s, wrqm/s 를 모니터링하면 디스크가 관리할 수 있는 merged 된 읽기와 쓰기의 숫자의 효과를 볼 수 있다. ** 여기서 merged는 여러개의 요청을 한꺼번에 모아서 처리하는 것을 말하는 듯 하다.

퍼포먼스 튜닝 옵션

워크로드가 순차적인 형태이고 컨트롤러의 대역폭이 꽉 차는 경우에는 더 빠른 디스크 컨트롤러를 추가해야 한다. 그러나 워크로드가 임의적인 형태이면 병목현상은 디스크 드라이브에서 생기므로 더 많은 드라이브를 추가하는 것이 성능향상에 도움이 될 것이다.

RAID 환경에서 더 많은 디스크 드라이브를 추가한다. 데이타를 여러개의 물리적인 디스크로 분산하여 read, write 성능향상을 할 수 있다. 초당 i/o 숫자를 늘릴 것이다. 소프트웨어 레이드 대신에 하드웨어 레이드를 사용한다.

메모리를 추가. 메모리를 추가하면 시스템 메모리 디스크 캐쉬가 늘어나서 디스크 응답 시간을 개선할 수 있다.

Labels
  • No labels