Estou executando um grande pool ZFS criado para leituras e gravações sequenciais com tamanho de solicitação de 256K + via iSCSI (para backups) no Ubuntu 18.04. Dada a necessidade de alta taxa de transferência e eficiência de espaço, e menos necessidade de desempenho aleatório de blocos pequenos, fui com raidz2 listrado sobre espelhos listrados.
No entanto, o desempenho de leitura sequencial de 256K é muito menor do que eu esperava (100 - 200MBps, picos de até 600MBps). Quando os zvols atingem ~ 99% de iowait no iostat, os dispositivos de suporte geralmente rodam entre 10 e 40% de iowait, o que sugere para mim o gargalo é algo que estou perdendo na configuração, já que não deve ser o backplane ou as CPUs esse sistema e cargas de trabalho seqüenciais não devem trabalhar muito o ARC.
Eu brinquei bastante com os parâmetros do módulo (configuração atual abaixo), li centenas de artigos, problemas no github do OpenZFS, etc. A pré-busca e agregação de ajuste me levaram a esse nível de desempenho - por padrão, eu estava rodando a cerca de 50 MBps em leituras seqüenciais quando o ZFS estava enviando solicitações TINY para os discos (~ 16K). Com a agregação e a pré-busca funcionando bem (eu acho), as leituras de disco são muito maiores, em torno de ~ 64K em média no iostat.
As NICs são o destino LIO iscsi com descarregamento de cxgbit + o iniciador do Windows Chelsio iscsi funciona bem fora dos zvols do ZFS, com um optano diretamente mapeado retornando quase a taxa de linha completa nas NICs (~ 3,5 GBps de leitura e gravação).
Estou esperando demais? Eu sei que o ZFS prioriza a segurança sobre o desempenho, mas eu esperaria que um raidz2 7x9 proporcionasse melhores leituras sequenciais do que um único raid mdadm de 9 unidades6.
Especificações do sistema e arquivos de registro / configuração:
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
Configuração do pool:
ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all
Configuração do ZVol:
sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)
Layout da piscina:
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
Estou arrancando meu cabelo com isso. Há pressão dos usuários para usarem todos os Windows com espaços de armazenamento, mas eu usei espaços de armazenamento com paridade (mesmo com espaços de armazenamento diretos com espelhos na parte superior), e isso também não é bom. Estou tentado a ir direto ao mdadm raid60 sob o iSCSI, mas adoraria se alguém pudesse apontar alguma coisa idiota que estou perdendo que desbloqueia o desempenho com a proteção bitrot do ZFS :)
fonte