여기서는 작은 스트라이프 크기가 Linux의 소프트웨어(및 하드웨어) RAID 5 및 6에 적합하지 않다는 내용을 읽었습니다. 내가 본 드문 벤치마크는 이에 완전히 동의합니다.
그러나 주어진 설명은 그것이 더 많은 머리 움직임을 유발한다는 것입니다. 나는 작은 줄무늬가 어떻게 머리를 더 많이 움직이게 하는지 이해하지 못합니다.
4개의 로컬 SAS 드라이브가 포함된 RAID 6 설정이 있다고 가정해 보겠습니다.
사례 1: 1Gb의 순차 데이터 쓰기
프로그램은 커널에 데이터 쓰기를 요청한 다음 이를 스트라이프 크기에 맞게 나누고 각 디스크에 쓸 각 블록(데이터 및/또는 패리티)을 계산합니다.
커널은 적절한 디스크 컨트롤러를 사용하여 4개의 디스크에 동시에 쓸 수 있습니다.
기록된 데이터가 스트라이프와 완벽하게 정렬되지 않은 경우 커널은 결과 데이터를 계산하기 전에 첫 번째와 마지막 스트라이프만 읽어야 합니다. 다른 모든 스트립은 이전 데이터에 관계없이 덮어쓰여집니다.
이 계산은 디스크 처리량보다 훨씬 빠르게 완료되므로 각 블록은 일시 중지 없이 각 디스크의 이전 블록 바로 옆에 기록됩니다. 따라서 이것은 기본적으로 4개의 디스크에 대한 순차적 쓰기입니다.
작은 스트라이프 크기로 인해 속도가 어떻게 느려지나요?
사례 2: 무작위 위치에 1,000,000 x 1kb의 데이터를 씁니다.
1kb는 스트라이프 크기(현재 일반적인 스트라이프 크기는 512kb)보다 작으며
프로그램은 커널에 일부 데이터, 다른 데이터, 다시 다른 데이터 등을 쓰도록 요청합니다. 각 쓰기에 대해 커널은 현재 데이터를 읽어야 합니다. 데이터를 디스크에 저장하고 새 콘텐츠를 계산한 후 다시 디스크에 씁니다. 그런 다음 머리가 다른 곳으로 이동하고 작업이 999,999회 반복됩니다.
스트라이프 크기가 작을수록 데이터 읽기/계산/쓰기 속도가 빨라집니다. 이상적으로는 4kb의 스트라이프 크기가 최신 디스크에 최적입니다(올바르게 정렬된 경우).
그렇다면 작은 스트립 크기가 어떻게 속도를 늦추나요?
답변1
내가 아는 한, 이 문제는 머리 움직임과 관련된 것이 아니며 모두 더 많은 오버헤드로 인해 발생합니다. 지정된 순차 읽기 또는 쓰기의 경우 4KB 스트라이프 크기는 64KB 스트라이프 크기보다 16배 더 많은 작업을 수행합니다. 더 많은 CPU 시간, 더 많은 메모리 대역폭, 더 많은 컨텍스트 전환, 더 많은 I/O, 커널 I/O 스케줄러에 대한 더 많은 작업, 더 많은 계산 병합 등으로 인해 궁극적으로 모든 I/O O에는 더 많은 지연이 발생하게 됩니다.
많은 애플리케이션이 대기열 크기가 1인 I/O를 실행하므로 16개의 4KB 순차 요청을 디스크에 대한 64KB 요청으로 항상 통합할 수 있는 것은 아닙니다.
또한 일반적인 ATTO 디스크 벤치마크를 보면 다음과 같습니다.
128KB 이상의 블록에서 읽기가 완료될 때까지 디스크는 최고 속도로 순차적으로 읽을 수도 없다는 것을 알 수 있습니다.
Tomshardware는 스트라이프 크기의 영향에 대해 매우 포괄적인 검토를 제공합니다.
http://www.tomshardware.com/reviews/RAID-SCALING-CHARTS,1735.html
답변2
저는 Linux 소프트웨어 RAID에 대해 이야기하고 있습니다. 당신이 볼 때코드를 입력, md 드라이버가 완전히 최적화되지 않은 것을 알 수 있습니다. 여러 개의 연속 요청이 생성되면 md 드라이버가 더 큰 요청으로 병합되지 않습니다. 일부 일반적인 경우 이로 인해 상당한 오버헤드가 발생할 수 있습니다.
대규모 읽기 또는 쓰기는 최적화됩니다. 스트라이프와 동일한 크기의 몇 가지 요청으로 축소되어 최적으로 처리됩니다.
읽기 또는 쓰기가 2개의 스트라이프에 걸쳐 있으면 md 드라이버가 작업을 올바르게 수행하는 것입니다. 모든 것이 한 번의 작업으로 처리됩니다.
작은 읽기의 경우 첫 번째 읽기 후 데이터가 커널 캐시에 있으므로 문제가 없습니다. 따라서 다중 연속 읽기는 느린 디스크 대역폭에 비해 CPU 및 메모리에 작은 오버헤드만 부과합니다.
예를 들어, 한 번에 100바이트씩 1Gb의 데이터를 읽습니다. 커널은 먼저 이를 512kb 읽기로 변환합니다. 왜냐하면 이것이 최소 I/O 크기이기 때문입니다(스트라이프 크기가 512kb인 경우). 따라서 다음 100바이트는 이미 커널 캐시에 있습니다. 이는 RAID가 아닌 파티션에서 읽는 것과 정확히 동일합니다.
스트라이프 크기보다 작은 쓰기의 경우 md 드라이버는 먼저 전체 스트라이프를 메모리로 읽은 다음 메모리를 새 데이터로 덮어쓴 다음 결과를 계산하고(패리티가 사용되는 경우)(주로 RAID 5 및 6) 복사합니다. 디스크에 쓰기.
예를 들어, 한 번에 100바이트씩 1Gb의 데이터를 씁니다. 커널은 먼저 512kb 스트립을 읽고, 메모리에서 필요한 부분을 덮어쓰고, 패리티가 포함되어 있으면 결과를 계산한 다음 디스크에 씁니다. 다음 100바이트를 쓸 때 데이터가 커널 캐시에 있기 때문에 "512kb 스트립 읽기"만 방지됩니다. 따라서 메모리를 덮어쓰고 패리티를 계산하는 데 약간의 오버헤드가 발생하지만 데이터가 동일한 스트라이프에 다시 기록되므로 오버헤드가 큽니다. 여기의 커널 코드는 최적화되지 않았습니다.
이러한 반복된 쓰기가 올바르게 캐시되지 않고 데이터가 몇 초 후에만 디스크에 플러시되는 이유를 이해하기 위해 충분한 조사를 수행하지 않았습니다(따라서 스트라이프당 한 번만). 캐시된 경우 오버헤드는 일부 CPU와 메모리에 불과하지만 내 자체 벤치마크에 따르면 CPU는 여전히 10% 미만이고 I/O가 병목 현상을 일으키는 것으로 나타났습니다.
쓰기가 최적화되면 최소 스트라이프 크기는 항상 최적입니다. 디스크가 4개 있는 RAID 6, 4k 섹터는 8kb 스트라이프를 생성하고 가능한 모든 로드에 대해 최고의 읽기 및 쓰기 처리량이 됩니다.
답변3
모든 것과 마찬가지로 중간 지점이 있습니다. 하지만 문제의 본질을 이해하려면 RAID2 및 RAID3(두 유형 모두 거의 사용되지 않음)을 살펴보는 것이 좋습니다.
그러나 이는 기본적으로 IO 대기 시간 및 동시 데이터 전송으로 귀결됩니다. 각 읽기 IO 작업에는 헤드 탐색 및 드라이브 회전에 대한 몇 밀리초의 오버헤드가 있습니다.
데이터 블록이 더 크면 이 페널티를 덜 자주 지불합니다. 이는 보다 원시적인 형태의 프리페치와 매우 유사합니다. 이러한 오버헤드로 인해 일반적으로 데이터를 요청할 때 여러 개의 데이터 청크를 프리페치하는 것이 좋습니다. 통계적으로 어쨌든 필요할 가능성이 높기 때문입니다.
하지만 가장 중요한 것은 쇼라는 것입니다.동조엄격한 규칙보다는 조치 - 디스크로 전송되는 작업 부하에 따라 블록 크기를 설정해야 합니다. 워크로드가 혼합되거나 무작위인 경우 이를 수행하는 것이 점점 더 어려워집니다. 블록이 클수록 처리량이 늘어나고 IO 작업이 줄어듭니다.대개IO 작업은 드라이브 속도를 제한하는 요소이므로대개더 큰 수요를 만드는 데 도움이 됩니다.
특정 사용 사례(예: 데이터베이스!)의 경우 이는 적용되지 않을 수 있습니다.