Linux-실제 하드웨어 RAID 컨트롤러 튜닝 (scsi 및 cciss)

내가 관리하는 대부분의 Linux 시스템은 기능 하드웨어 RAID 컨트롤러 (대부분 HP Smart Array )입니다. 그들은 모두 RHEL 또는 CentOS를 실행하고 있습니다.

SAS 디스크 (Smart Array, Perc, LSI 등) 및 배터리 백업 또는 플래시 백업 캐시가있는 하드웨어 RAID 컨트롤러를 통합 한 설정의 성능을 최적화 할 수있는 실제 튜너 블을 찾고 있습니다. RAID 1 + 0 및 여러 스핀들 (4+ 디스크)을 가정하십시오.

지연 시간이 짧고 금융 거래 응용 프로그램에 대한 Linux 네트워크 설정을 조정하는 데 상당한 시간이 걸립니다. 그러나 이러한 옵션 중 많은 부분이 문서화되어 있습니다 (송수신 버퍼 변경, TCP 창 설정 수정 등). 스토리지 측에서 엔지니어는 무엇을하고 있습니까?

과거에는 I / O 스케줄링 엘리베이터를 변경하여 최근에 내 응용 프로그램 내에서 성능을 향상시키기 위해 deadline및 noop스케줄러를 선택했습니다 . RHEL 버전이 발전함에 따라 SCSI 및 CCISS 블록 장치의 컴파일 된 기본값도 변경되었음을 알았습니다. 이는 시간이 지남에 따라 권장 스토리지 서브 시스템 설정에 영향을 미쳤습니다. 그러나 명확한 권장 사항을 본 이후로 시간이 오래 걸렸습니다. 그리고 OS 기본값이 최적이 아님을 알고 있습니다. 예를 들어 서버 클래스 하드웨어에 배포 할 때 기본 미리 읽기 버퍼 인 128kb는 매우 작은 것 같습니다.

다음 기사에서는 미리 읽기 캐시 및 nr_requests 값을 변경하여 블록 큐에 미치는 성능 영향을 살펴 봅니다 .

http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with -linux-why-tuning-really-matters
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html

예를 들어, 다음은 HP Smart Array RAID 컨트롤러에 대한 제안 된 변경 사항입니다.

echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler 
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb

스토리지 성능을 향상시키기 위해 다른 무엇을 안정적으로 조정할 수 있습니까?
프로덕션 시나리오에서 sysctl 및 sysfs 옵션을 구체적으로 찾고 있습니다.

지연 시간 대 처리량을 줄이려고 할 때 nr_requests를 기본값에서 32까지 낮게 조정했습니다. 배치가 작다는 아이디어는 지연 시간이 줄어 듭니다.

또한 read_ahead_kb의 경우 순차적 읽기 / 쓰기의 경우이 값을 높이면 처리량이 향상되지만이 옵션은 실제로 작업량과 IO 패턴에 달려 있음을 알았습니다. 예를 들어 최근에 조정 한 데이터베이스 시스템에서이 값을 단일 db 페이지 크기와 일치하도록 변경하여 읽기 대기 시간을 줄였습니다. 이 값 이상으로 증가 또는 감소하면 필자의 경우 성능이 저하되는 것으로 판명되었습니다.

블록 장치 큐에 대한 다른 옵션 또는 설정과 관련하여 :

max_sectors_kb = 하드웨어가 단일 전송에 허용하는 것과 일치하도록이 값을 설정했습니다 (sysfs에서 max_hw_sectors_kb (RO) 파일의 값을 확인하여 허용되는 것을 확인하십시오)

nomerges = io 요청 병합을위한 조회 로직을 비활성화하거나 조정할 수 있습니다. (이 기능을 끄면 CPU 사이클이 절약 될 수 있지만 시스템을 변경할 때 아무런 이점이 없으므로 기본값으로 두었습니다)

rq_affinity = 아직 시도하지는 않았지만 커널 문서에서 그 뒤에 설명이 있습니다.

이 옵션이 '1'인 경우 블록 계층은 요청 완료를 원래 요청을 제출 한 CPU "그룹"으로 마이그레이션합니다. 일부 워크로드의 경우 캐싱 효과로 인해 CPU주기가 크게 줄어 듭니다.
완료 처리의 분배를 최대화해야하는 스토리지 구성의 경우이 옵션을 '2'로 설정하면 요청하는 CPU ( "그룹"집계 논리 무시)에서 완료가 강제 실행됩니다 "

스케줄러는 = 당신은 당신이 마감 및 무 조작을 시도했다. 나는 noop과 데드 라인을 모두 테스트했지만 데이터베이스 서버에 대해 가장 최근에 수행 한 테스트에서 데드 라인이 승리 한 것으로 나타났습니다.

NOOP는 잘 수행되었지만 데이터베이스 서버의 경우 마감일 스케줄러를 조정하여 더 나은 성능을 달성 할 수있었습니다.

/ sys / block / {sd, cciss, dm-} * / queue / iosched / 아래에있는 최종 기한 스케줄러 옵션 :

fifo_batch = nr_requests 와 비슷하지만 스케줄러에 따라 다릅니다. 일반적으로 지연 시간을 줄이거 나 처리량을 높이려면이 수준을 낮추십시오. 읽기 및 쓰기 요청의 배치 크기를 제어합니다.

write_expire = 쓰기 배치의 만료 시간을 설정합니다. 기본값은 5000ms입니다. 이 값을 다시 낮추면 쓰기 대기 시간이 줄어들고 값이 증가하면 처리량이 증가합니다.

read_expire = 읽기 배치의 만료 시간을 설정합니다. 기본값은 500ms입니다. 여기에도 같은 규칙이 적용됩니다.

front_merges = 나는 이것을 끄는 경향이 있으며 기본적으로 켜져 있습니다. 스케줄러가 IO 요청을 병합하려고 시도하는 CPU 사이클을 낭비 할 필요가 없습니다.

writes_starved = 최종 기한이 읽기에 맞춰 지므로 여기서 기본값은 쓰기 배치가 처리되기 전에 2 개의 읽기 배치를 처리하는 것입니다. 워크로드에 적합한 기본값 2를 찾았습니다.

무엇보다 모든 것이 작업량에 달려 있습니다.

read_ahead_kb비디오를 스트리밍 할 때와 같이 일부 파일에서 많은 양의 데이터를 미리 읽는 것이 도움이되는 경우 도움이 될 수 있습니다. 때로는 심하게 다칠 수 있습니다. 예, 기본 128KB는 작게 들릴 수 있지만 동시성이 충분하면 크게 들리기 시작합니다! 한편, 비디오 인코딩 서버와 같은 서버를 사용하여 비디오를 형식에서 다른 형식으로 만 변환하는 것은 튜닝하는 것이 좋습니다.

nr_requests과도하게 조정되면 RAID 컨트롤러를 쉽게 넘칠 수있어 성능이 다시 저하됩니다.

실제로는 대기 시간 을 지켜봐야합니다 . SAN에 연결되어있는 경우 iostat, sar또는 사용하려는 항목을 살펴보고 I / O 요청 서비스 시간이 지붕을 통과하는지 확인하십시오. 물론 이것은 로컬 디스크에도 도움이됩니다. 지연 시간이 매우 큰 경우 max_requests 및 기타 설정을 다운 그레이드하여 I / O 엘리베이터 설정을 조정 해보십시오.

참고 read_ahead_kb및 blockdev --setra단지입니다 서로 다른 단위를 사용하여 동일한 설정을 설정하는 여러 가지 방법 (섹터 대 킬로바이트)

foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096

그래서

blockdev --setra 65536 /dev/cciss/c0d0

귀하의 예에서는 효과가 없습니다.