dr - Minha matriz ZFS RAIDZ2 lê a 7,5+ GB/s e grava a 2,0+ GB/s quando eu especifico um bs=128Kou superior com dd. OS X está assumindo 1K (conforme stat -f %k .) e todo o meu é de aproximadamente 300 MB/s; dddá o mesmo desempenho com bs=1k. Até mesmo bs=4kdá 1,1 GB/s com dd.
O que posso fazer para melhorar a E/S geral para pelo menos 1 GB/s?
--
Detalhes:
Estou executando um sistema de arquivos SATA3 RAIDZ2 OpenZFS de 16 unidades no sistema de arquivos OSX (v1.31r2) (v5000) sobre Thunderbolt 2 (areca 8050T2 duplo) em um Mac Pro de 64 GB de 12 núcleos.
O sistema de arquivos ZFS foi criado com ashift=12(HDDs de formato avançado com blocos de 4096 bytes) e um arquivo recordsize=128k.
Estou vendo taxas de transferência em torno de 300 MB/s do array no OS X e do terminal usando comandos padrão (o arquivo de observação que está sendo copiado contém dados aleatórios de 10 GB):
Cópia normal:
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
≈ 424MB/s
--
ddcom 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/s
--
ddcombs=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,16 GB/s
--
ddcom 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,67 GB/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
--
Também criei um volume ZFS no pool ao lado do sistema de arquivos e formatei como HFS+. Obtive o mesmo desempenho acima.
Estou rodando cerca de 20-30x abaixo do ideal! o que estou perdendo? Alguma ideia?
--
Atualização: altas velocidades foram armazenadas em cache de E/S (obrigado @yoonix). Velocidades de ≈300 MB/s ainda parecem muito lentas para este hardware.
@qasdfdsaq: a utilização da CPU durante a E/S é insignificante (todos os núcleos <5%).
zfs obtém todas as saídas:
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
Responder1
Você não postou zpool statusisso, mas sugere na postagem que todos os 16 discos estão em um único vdev no RAIDZ2. Embora esta seja uma configuração boa e segura, você deve entender que o RAIDZ não foi projetado principalmente para velocidade. Ele foi projetado para ser quase à prova de balas. RAIDZ2 é análogo ao RAID6, mas a variante possui recursos que o tornam mais lento e seguro.
Veresse belo textopara obter todos os detalhes, mas essas duas citações devem ajudá-lo a ver o problema (ênfase minha):
Ao gravar em vdevs RAID-Z, cada bloco do sistema de arquivos é dividido em sua própria faixa em (potencialmente) todos os dispositivos do vdev RAID-Z. Isso significa que cada E/S de gravação terá que esperar até que todos os discos no vdev RAID-Z terminem de ser gravados. Portanto, do ponto de vista de um único aplicativo aguardando a conclusão de seu IO,você obterá o desempenho de gravação IOPS do disco mais lento no RAID-Z vdev.
Ao ler de vdevs RAID-Z, as mesmas regras se aplicam, pois o processo é essencialmente revertido (sem atalho round robin como no caso de espelhamento): Melhor largura de banda se você tiver sorte (e leia da mesma maneira que escreveu)e o desempenho de leitura de IOPS de um único disco na maioria dos casos importantes.
Na verdade, você tem 16 unidades de velocidade média e, para cada passagem de gravação, espera que todas as 16 unidades façam check-in com o controlador e digam "concluído" antes do início da próxima gravação. Com 16 discos, você sempre esperará por uma rotação quase completa do disco antes de uma das gravações, para que você seja prejudicado pela física e pela forma como o ZFS confirma os dados.
Tarefas de gravação de processo/thread único não são o melhor caso para o ZFS em geral. A execução de várias tarefas pequenas de leitura/gravação de dados ao mesmo tempo pode mostrar melhores números de IOPS, mas acho que a física do ZFS é o seu principal problema.
Se você estiver disposto a sacrificar o espaço, o espelhamento provavelmente será mais rápido. Você também pode obter um desempenho ligeiramente melhor do ZFS criando 2 vdevs RAIDZ2 de 8 discos no pool em vez de 1 vdev RAIDZ2 de 16 discos. Isso também custará espaço de armazenamento utilizável, mas pode ajudar os commits a acontecerem mais rapidamente.
Infelizmente não tenho boas notícias para você.