9x7 드라이브 RAIDZ2 (ZFS ZoL 0.8.1)에서 느린 순차 속도

Ubuntu 18.04에서 iSCSI (백업용)를 통해 256K + 요청 크기 순차 읽기 및 쓰기를 위해 구축 된 대형 ZFS 풀을 실행하고 있습니다. 높은 처리량과 공간 효율성이 필요하고 임의의 작은 블록 성능이 덜 필요하다는 점을 감안할 때 스트라이프 미러보다 스트라이프 raidz2를 사용했습니다.

그러나 256K 순차 읽기 성능은 예상보다 훨씬 낮습니다 (100-200MBps, 최대 600MBps). zio가 iostat에서 ~ 99 % iowait에 도달하면 백업 장치는 일반적으로 10 ~ 40 % iowait 사이에서 실행되므로 병목 현상은 구성에서 누락되었거나 백플레인이나 CPU가 아니어야 함을 나타냅니다. 이 시스템과 순차적 워크로드는 ARC를 너무 열심히 작동하지 않아야합니다.

나는 모듈 매개 변수 (아래의 현재 구성)로 꽤 많이 연주했으며, 수백 개의 기사를 읽었으며 OpenZFS github에 대한 문제 등을 읽었습니다. 프리 페치 및 집계 조정이이 성능 수준에 도달했습니다. 기본적으로 약 ~ 50MBps에서 실행 중이었습니다. ZFS가 TINY 요청을 디스크 (~ 16K)로 전송하는 동안 순차적 읽기. 집계 및 프리 페치가 정상적으로 작동하면 (iostat) 디스크 읽기가 평균 ~ 64K 정도로 훨씬 높습니다.

NIC는 cxgbit 오프로드가있는 LIO iscsi 대상이며 Windows Chelsio iscsi 초기자는 ZFS zvol 외부에서 잘 작동하며, 옵 테인은 NIC에서 거의 전체 회선 속도 (약 3.5GBps 읽기 및 쓰기)를 반환하여 직접 매핑됩니다.

너무 많이 기대하고 있습니까? ZFS가 성능보다 안전을 우선시한다는 것을 알고 있지만 7x9 raidz2가 단일 9 드라이브 mdadm raid6보다 더 나은 순차적 읽기를 제공 할 것으로 기대합니다.

시스템 사양 및 로그 / 구성 파일 :

Chassis: Supermicro 6047R-E1R72L
HBAs: 3x 2308 IT mode (24x 6Gbps SAS channels to backplanes)
CPU: 2x E5-2667v2 (8 cores @ 3.3Ghz base each)
RAM: 128GB, 104GB dedicated to ARC
HDDs: 65x HGST 10TB HC510 SAS (9x 7-wide raidz2 + 2 spares)
SSDs: 2x Intel Optane 900P (partitioned for mirrored special and log vdevs)
NIC: Chelsio 40GBps (same as on initiator, both using hw offloaded iSCSI)
OS: Ubuntu 18.04 LTS (using latest non-HWE kernel that allows ZFS SIMD)
ZFS: 0.8.1 via PPA
Initiator: Chelsio iSCSI initiator on Windows Server 2019

풀 구성 :

ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all

ZVol 구성 :

sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)

수영장 레이아웃 :

7x 9-wide raidz2
mirrored 200GB optane special vdev (SPA metadata allocation classes)
mirrored 50GB optane log vdev

/etc/modprobe.d/zfs.conf :

# 52 - 104GB ARC, this system does nothing else
options zfs zfs_arc_min=55834574848
options zfs zfs_arc_max=111669149696

# allow for more dirty async data
options zfs zfs_dirty_data_max_percent=25
options zfs zfs_dirty_data_max=34359738368

# txg timeout given we have plenty of Optane ZIL
options zfs zfs_txg_timeout=5

# tune prefetch (have played with this 1000x different ways, no major improvement except max_streams to 2048, which helped, I think)
options zfs zfs_prefetch_disable=0
options zfs zfetch_max_distance=134217728
options zfs zfetch_max_streams=2048
options zfs zfetch_min_sec_reap=3
options zfs zfs_arc_min_prefetch_ms=250
options zfs zfs_arc_min_prescient_prefetch_ms=250
options zfs zfetch_array_rd_sz=16777216

# tune coalescing (same-ish, increasing the read gap limit helped throughput in conjunction with low async read max_active, as it caused much bigger reads to be sent to the backing devices)
options zfs zfs_vdev_aggregation_limit=16777216
options zfs zfs_vdev_read_gap_limit=1048576
options zfs zfs_vdev_write_gap_limit=262144

# ZIO scheduler in priority order 
options zfs zfs_vdev_sync_read_min_active=1
options zfs zfs_vdev_sync_read_max_active=10
options zfs zfs_vdev_sync_write_min_active=1
options zfs zfs_vdev_sync_write_max_active=10
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=2
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4

# zvol threads
options zfs zvol_threads=32

나는 이것에 머리카락을 찢어 버리고있다. 스토리지 공간이있는 모든 Windows로 이동 해야하는 압력이 있지만 패리티 스토리지 공간 (스토리지 공간이 Direct가있는 미러도 있음)을 사용했지만 그다지 좋지 않습니다. iSCSI에서 mdadm raid60을 사용하고 싶었지만 누군가가 누락 된 부분을 지적하면 ZFS의 비트 롯 보호로 성능을 잠금 해제 할 수있는 것을 좋아할 것입니다. :)

좋은 질문.

• 스파 스 zvol 블록 크기는 128k 여야한다고 생각합니다.
• ZIO 스케줄러 설정은 모두 최소 10 및 최대 64와 같이 높아야합니다.
• zfs_txg_timeout이 훨씬 길어야합니다. 내 시스템에서 15 또는 30 대를 수행합니다.
• 여러 RAIDZ3 (또는 오타)이 과도하게 사용되어 성능에 큰 영향을 미친다고 생각합니다. RAIDZ2로 벤치마킹 할 수 있습니까?

편집 : 시스템에 Netdata 를 설치 하고 사용률 및 ZFS 통계를 모니터링합니다.

Edit2 : Veeam 저장소를위한 것입니다. Veeam은 Linux를 대상으로 지원하며 ZFS와 훌륭하게 작동합니다. 데이터로 벤치마킹을 고려 하시겠습니까? NIC의 오프로드가 솔루션의 중요한 부분이 아니라면 zvols는 현재 수행중인 작업에 이상적인 사용 사례가 아닙니다.