Le pool est composé de deux disques durs (WD Red 3 TB, 5200 RPM ?, taux de transfert max. 147 MB/s & Verbatim (Toshiba) 3 TB, 7200 RPM) dans le système de gestion des données. raidz1-0 configuration. Il contient 2,25 To de données, dupliquées sur deux disques, soit un total de 4,5 To. Lorsque j'ai créé le pool, je n'ai pas spécifié de nom de domaine. ashift valeur.
zpool status montre que "scan : scrub repaired 0 in 32h43m with 0 errors on Sun Jan 3 13:58:54 2021". Cela signifie que la vitesse d'analyse était seulement 4.5e6 / (32.717 * 60 * 60) = 38.2 MB / s . Je m'attendrais à au moins 2 x 100 ou jusqu'à 2 x 200 Mo/s, bien que le disque WD soit un peu plus lent que l'autre.
Les données SMART des disques montrent que tout est sain. Ils ont 6,5 à 7 ans de durée de fonctionnement, mais le nombre de démarrages et d'arrêts n'est que de 200 environ.
Donc la question principale : Qu'est-ce qui pourrait expliquer les mauvaises performances de lecture ?
Curieusement zdb a montré que le pool utilise le chemin /dev/disk/by-id/ata-WDC_WD30EFRX-xyz-part1 plutôt que /dev/disk/by-id/ata-WDC_WD30EFRX-xyz . fdisk -l /dev/disk/by-id/ata-WDC_WD30EFRX-xyz mentionne que "la partition 1 ne démarre pas sur la limite du secteur physique", mais j'ai lu que cela ne devrait affecter que les performances d'écriture. Je pourrais essayer de résoudre ce problème en supprimant le périphérique et en le remettant en place avec le chemin d'accès au disque complet approprié, puisque les données sont dupliquées (et sauvegardées).
Le pool contient 7,1 millions de fichiers. J'ai testé l'exécution de sha1sum sur un fichier de 14276 MB après avoir vidé les caches via /proc/sys/vm/drop_caches il a fallu 2 min 41 s, ce qui donne une vitesse de lecture de 88,5 Mo/s.
dd bs=1M count=4096 if=/dev/disk/by-id/ata-WDC_WD30EFRX-xyz of=/dev/null a indiqué une vitesse de 144 MB/s, en l'utilisant sur ata-WDC_WD30EFRX-xyz-part1 a rapporté 134 MB/s et ata-TOSHIBA_DT01ACA300_xyz a rapporté 195 MB/s.
Mon NAS fonctionne avec des versions logicielles assez anciennes :
$ modinfo zfs
filename: /lib/modules/3.11.0-26-generic/updates/dkms/zfs.ko
version: 0.6.5.4-1~precise
license: CDDL
author: OpenZFS on Linux
description: ZFS
srcversion: 5FC0B558D497732F17F4202
depends: spl,znvpair,zcommon,zunicode,zavl
vermagic: 3.11.0-26-generic SMP mod_unload modversions Il dispose de 24 Go de RAM, dont 8 Go sont réservés à une JVM, le reste étant libre d'être utilisé. Bien que le reste ne semble pas être libre :
$ free -m
total used free shared buffers cached
Mem: 23799 21817 1982 0 273 1159
-/+ buffers/cache: 20384 3415
Swap: 7874 57 7817Edit 1 :
J'ai fait quelques tests avec bonnie++ En utilisant un seul fichier de 4 Go sur le RAIDZ : écriture 75,9 Mo/s, réécriture 42,2 Mo/s et lecture 199,0 Mo/s. Je suppose que j'ai fait la conversion correctement à partir des "kilo-caractères / seconde".
Ah, je viens de réaliser que le scrub parallèle prend autant de temps que le disque 5400 RPM le plus lent, peu importe que le 7200 RMP ait été (éventuellement) scrubé plus rapidement.
Edit 2 :
J'ai réduit le nombre de fichiers dans le pool de 7,1 millions à 4,5 millions (-36,6%) et le temps de scrub est passé de 32,72 heures à 16,40 heures (-49,9%). La quantité de données est la même puisque j'ai simplement placé ces petits fichiers dans un ZIP à faible compression.
J'ai aussi augmenté le recordsize de 128k à 512k, je ne sais pas si cela a fait une différence dans ce cas. Les autres données préexistantes n'ont pas été touchées, elles conservent donc l'aspect original. recordsize . Oh et /sys/module/zfs/parameters/zfs_scan_idle a été fixé à 2 .
