bs=128Ktl;dr - 로 a 이상을 지정하면 내 ZFS RAIDZ2 어레이는 7.5GB/s 이상으로 읽고 2.0GB/s 이상으로 씁니다 dd. OS X는 (에 따라 stat -f %k .) 1K를 가정하고 내 모든 것은 ~300MB/s입니다. dd와 동일한 성능을 제공합니다 bs=1k. a도 bs=4kdd를 사용하면 1.1GB/s를 제공합니다.
일반 I/O를 최소 1GB/s로 향상하려면 어떻게 해야 합니까?
--
세부:
저는 Thunderbolt 2(트윈 Areca 8050T2)를 통해 OSX(v1.31r2) 파일 시스템(v5000)에서 16개 드라이브 SATA3 RAIDZ2 OpenZFS를 12코어 64GB Mac Pro로 실행하고 있습니다.
ZFS 파일 시스템은 ashift=12(4096바이트 블록의 고급 포맷 HDD) 및 recordsize=128k.
OS X의 어레이와 기본 명령을 사용하는 터미널에서 전송 속도는 약 300MB/s입니다(복사되는 파일은 10GB 임의 데이터임).
일반 사본:
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
≒ 424MB/초
--
dd와 함께 bs=1k:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)
real 0m32.575s
user 0m1.880s
sys 0m30.695s
≒ 309MB/초
--
dd~와 함께bs=4k
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)
real 0m8.688s
user 0m0.460s
sys 0m8.228s
1.16GB/초
--
dd와 함께 bs=2m:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)
real 0m1.165s
user 0m0.003s
sys 0m1.162s
약 8.67GB/s
--
OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096
--
OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024
--
또한 파일 시스템과 함께 풀에 ZFS 볼륨을 만들고 HFS+로 포맷했습니다. 위와 같은 성능을 얻었습니다.
최적 수준보다 ~20-30배 낮은 수준으로 실행 중입니다! 내가 무엇을 놓치고 있나요? 어떤 아이디어가 있나요?
--
업데이트: 빠른 속도의 I/O가 캐시되었습니다(@yoonix에게 감사드립니다). 300MB/s의 속도는 이 하드웨어에 비해 여전히 너무 느린 것 같습니다.
@qasdfdsaq: I/O 중 CPU 사용률은 무시할 수 있습니다(모든 코어 <5%).
zfs는 모든 출력을 얻습니다.
NAME PROPERTY VALUE SOURCE
lb-bu type filesystem -
lb-bu creation Tue Sep 30 16:41 2014 -
lb-bu used 36.8T -
lb-bu available 10.0T -
lb-bu referenced 138M -
lb-bu compressratio 1.00x -
lb-bu mounted yes -
lb-bu quota none default
lb-bu reservation none default
lb-bu recordsize 128K default
lb-bu mountpoint /Volumes/lb-bu local
lb-bu sharenfs off default
lb-bu checksum on default
lb-bu compression lz4 local
lb-bu atime on default
lb-bu devices on default
lb-bu exec on default
lb-bu setuid on default
lb-bu readonly off default
lb-bu zoned off default
lb-bu snapdir hidden default
lb-bu aclmode discard default
lb-bu aclinherit restricted default
lb-bu canmount on default
lb-bu xattr on default
lb-bu copies 1 default
lb-bu version 5 -
lb-bu utf8only on -
lb-bu normalization formD -
lb-bu casesensitivity insensitive -
lb-bu vscan off default
lb-bu nbmand off default
lb-bu sharesmb off default
lb-bu refquota none default
lb-bu refreservation none default
lb-bu primarycache all default
lb-bu secondarycache all default
lb-bu usedbysnapshots 0 -
lb-bu usedbydataset 138M -
lb-bu usedbychildren 36.8T -
lb-bu usedbyrefreservation 0 -
lb-bu logbias latency default
lb-bu dedup off default
lb-bu mlslabel none default
lb-bu sync standard default
lb-bu refcompressratio 1.01x -
lb-bu written 138M -
lb-bu logicalused 36.8T -
lb-bu logicalreferenced 137M -
lb-bu snapdev hidden default
lb-bu com.apple.browse on default
lb-bu com.apple.ignoreowner off default
lb-bu com.apple.mimic_hfs off default
lb-bu redundant_metadata all default
lb-bu overlay off default
답변1
이에 대해 게시하지는 않았지만 zpool status게시물에서 16개 디스크가 모두 RAIDZ2의 단일 vdev에 있음을 암시합니다. 이는 훌륭하고 안전한 구성이지만 RAIDZ는 주로 속도를 위해 설계되지 않았다는 점을 이해해야 합니다. 방탄에 가깝게 설계되었습니다. RAIDZ2는 RAID6과 유사하지만 이 변형에는 더 느리고 안전한 기능이 있습니다.
보다이거 잘 쓰네자세한 내용은 다음 두 인용문을 통해 문제를 파악하는 데 도움이 될 것입니다(강조).
RAID-Z vdev에 쓸 때 각 파일 시스템 블록은 (잠재적으로) RAID-Z vdev의 모든 장치에 걸쳐 자체 스트라이프로 분할됩니다. 이는 각 쓰기 I/O가 RAID-Z vdev의 모든 디스크 쓰기가 완료될 때까지 기다려야 함을 의미합니다. 따라서 IO가 완료되기를 기다리는 단일 애플리케이션의 관점에서 볼 때,RAID-Z vdev에서 가장 느린 디스크의 IOPS 쓰기 성능을 얻을 수 있습니다.
RAID-Z vdev에서 읽을 때 프로세스가 본질적으로 반대이므로 동일한 규칙이 적용됩니다(미러링의 경우와 같은 라운드 로빈 단축키 없음). 운이 좋으면 대역폭이 더 좋습니다(작성한 것과 같은 방식으로 읽습니다).그리고 대부분의 경우 단일 디스크의 IOPS 읽기 성능이 중요합니다..
실제로 16개의 중간 속도 드라이브가 있고 각 쓰기 패스마다 16개 드라이브 모두가 컨트롤러에 체크인하고 다음 쓰기가 시작되기 전에 "완료"라고 말할 때까지 기다립니다. 16개의 디스크를 사용하면 쓰기 중 하나 전에 거의 전체 디스크 회전을 효과적으로 항상 기다리게 되므로 물리학과 ZFS가 데이터를 커밋하는 방식에 의해 지연됩니다.
단일 프로세스/스레드 쓰기 작업은 일반적으로 ZFS에 가장 적합한 경우가 아닙니다. 한 번에 여러 개의 작은 데이터 읽기/쓰기 작업을 실행하면 더 나은 IOPS 수치가 표시될 수 있지만 ZFS의 물리학이 주요 문제라고 생각합니다.
공간을 희생하려는 경우 미러링이 더 빠를 수 있습니다. 또한 풀에 16디스크 RAIDZ2 vdev 1개 대신 8디스크 RAIDZ2 vdev 2개를 만들어 ZFS에서 약간 더 나은 성능을 얻을 수도 있습니다. 이 역시 사용 가능한 저장 공간이 필요하지만 커밋이 더 빠르게 수행되는 데 도움이 될 수 있습니다.
안타깝게도 좋은 소식이 없습니다.