Réglage du nettoyage ZFS, 141 Ko / s en cours d'exécution pendant 15 jours

14

Un système assez basique exécutant miroir + bande sur des disques sas 7.2k rpm, pas particulièrement chargé. Pas de déduplication, compression sur tous les jeux de données. Scrub court depuis 15 jours à la vitesse d'un escargot mort. Y a-t-il une optimisation qui doit être faite, ou peut-elle être due à un matériel défectueux?

  • Dell R510 avec boîtier MD1200.
  • 2x Xeon E5620
  • 48 Go
  • NexentaStor 3.1.3, édition communautaire

Des informations:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

Le spa_last_io est changé chaque fois que je lance ce

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

Toutes les 5 secondes, environ 20-25 Mo / s sont écrits. Entre ces écritures, il n'y a fondamentalement aucune lecture ou écriture.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Est-ce que les iostats me disent que je passe plus de temps à attendre le disque alors que je devrais le faire? Plus précisément la colonne% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

La latence un peu trop élevée?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

Appliqué quelques ajustements qui ne faisaient guère de différence. zfs_top_maxinflight défini sur 127, zfs_scrub_delay sur 0 et zfs_scan_idle sur 0.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

pré-ajustement de mdb, notez la colonne b% plutôt élevée

$ iostat -nx -M 5 

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

post mdb tweak, notez la colonne b%, 80-85% de temps en attente occupée

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0
zfs  nexenta 
— 3molo
source
Quelle occurrence multiple d'iostat -XnE | erreurs grep dit? faire un incrément de nombre d'erreurs?
Zéro dans toutes les colonnes
— 3molo
Que smartctl -A /dev/diskdit-on de chaque lecteur (il peut être nécessaire d'installer smartctl, je ne sais pas s'il est fourni avec l'installation de base).
— Chris S
1
Rien d'intéressant, à part "Nombre d'erreurs non moyennes: 8071" sur un disque. Tous les disques sont placés dans un JBOD (Dell MD1200) sur la même (seule) voie sas
— 3molo

Réponses:

11

Les opérations de nettoyage de ZFS fonctionnent sur des principes assez cérébraux. Plus particulièrement, il ne passe du temps à nettoyer que lorsqu'il n'y a rien d'autre. Si vous percez un pool avec juste un peu d'accès aux données sur une base assez constante, scrub va effectivement se priver de nourriture et ne fera presque rien.

Tunables à explorer, avec mes notes rapides sur ce qu'il fait (j'ai pour la dernière fois examiné cela il y a un certain temps):

  • zfs_scan_idle - si les E / S utilisateur se produisent dans ce nombre d'horloge, retardez les E / S de scrub par zfs_scrub_delay
  • zfs_scrub_delay - combien de tics d'horloge pour retarder l'opération de scrub s'il est déclenché par zfs_scan_idle
  • zfs_top_maxinflight - nombre maximum d'E / S de scrub par vdev de niveau supérieur
  • zfs_scrub_limit - nombre maximum d'E / S de scrub par feuille vdev
  • zfs_scan_min_time_ms - ms minimum à dépenser par txg pour les opérations de scrub
  • zfs_no_scrub_io - pas de notes
  • zfs_no_scrub_prefetch - pas de notes, le nom semble impliquer de ne pas provoquer de prélecture sur les opérations de scrub

Tous ces éléments peuvent être modifiés à la volée en utilisant "echo [tunable] / W0t [nombre]" pour changer, et "echo [tunable] / D" pour afficher le réglage actuel (ce que je recommande de faire avant de changer).

Donc, en théorie et dans la pratique générale, si vous deviez, par exemple, changer zfs_scan_idle en 10 (ou 1 - ou 0, s'il le prend en charge, il faudrait vérifier le code) et zfs_scrub_delay en 1 (ou 0, si il prend en charge cela), et si votre paramètre txg_synctime_ms est 5000 ou plus, peut-être changer un peu zfs_scan_min_time_ms, il devrait devenir beaucoup plus agressif de faire des opérations de scrub même avec un certain niveau d'E / S utilisateur.

Dans votre cas spécifique, les% b et asvc_t signalés impliquent une charge de travail de lecture très, très aléatoire (les disques en rotation devraient faire mieux que si c'est vraiment séquentiel), et vous avez déjà fait le truc "facile" comme expliqué ci-dessus . Donc, je voudrais d'abord activer zfs_no_scrub_prefetch, pour désactiver la prélecture sur les opérations de scrub, juste pour voir si cela a aidé. En cas de non-joie, selon la version de Nexenta sur laquelle vous vous trouvez - vous exécutez peut-être 30/5, 5/1 ou 10/5 (c'est un raccourci que nous utilisons pour les paramètres de zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Remplacez zfs_txg_timeout par 10 et zfs_txg_synctime_ms par 5000, puis essayez de mettre zfs_scan_min_time_ms à 3000 ou 4000. Cela indique à ZFS qu'il peut consacrer beaucoup plus de temps aux gommages, par rapport aux paramètres par défaut des anciennes installations NexentaStor qui utilisent 5/1 comme valeurs par défaut, mais prudent,

J'espère que cela t'aides. Bonne chance!

— Nex7
source
Je suppose que je devrais noter que vous modifiez ces paramètres dans bash en utilisant "echo <tunable> / W0t <number> | mdb -kw". Et vous affichez les valeurs actuelles avec "echo <tunable> / D | mdb -k". Mes notes indiquent que tout cela peut être modifié en vol, aucun ne semble nécessiter une modification / etc / system et redémarrer pour prendre effet.
— Nex7
Je devrais également lire la question entière avant de répondre - et arrêter de parcourir ServerFault pendant les conférences téléphoniques. :)
— Nex7
Les% b et asvc_t rapportés impliquent une charge de travail de lecture très, très aléatoire (les disques en rotation devraient faire mieux que si c'est vraiment séquentiel). D'abord, j'activerais zfs_no_scrub_prefetch, pour désactiver la prélecture sur les opérations de scrub, juste pour voir si cela a aidé. Si vous n'êtes pas satisfait, selon la version de Nexenta sur laquelle vous vous trouvez - vous exécutez peut-être 30/5, 5/1 ou 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Remplacez zfs_txg_timeout par 10 et zfs_txg_synctime_ms par 5000, puis essayez augmenter zfs_scan_min_time_ms à 3000 ou 4000. Cela indique à ZFS qu'il peut passer beaucoup plus de temps sur les gommages, peut affamer les E / S normales!
— Nex7
Je pense que vous apportez une contribution très précieuse, mais il serait beaucoup plus utile si vous pouviez ajouter les commentaires dans une bonne réponse.
— 3molo
2
Plus de réglage peut avoir aidé, mais pas nécessairement. Il est important de noter qu'un scrub ZFS parcourt la structure des données, PAS secteur par secteur sur les disques. Autrement dit, en fonction de l'apparence de la structure de données zfs sur vos disques, une opération de nettoyage peut sembler incroyablement aléatoire - vos disques peuvent être capables de> 100 Mo / s de lecture séquentielle , mais une lecture complètement aléatoire sera une tout autre histoire . La taille moyenne des blocs importerait également ici.
— Nex7
3

Je soupçonne du matériel ...

Pourquoi voudriez-vous laisser cela fonctionner pendant 15 jours? Ce n'est pas normal. Arrêtez le nettoyage - zpool scrub -s tanket vérifiez le système.

  • Quels contrôleurs utilisez-vous?
  • Est-ce le premier gommage que vous ayez jamais exécuté sur cette piscine?
  • Un problème vous a-t-il incité à exécuter le gommage en premier lieu?
— ewwhite
source
1
LSI SAS9200-8e (firmware informatique). Pas le premier gommage. Non, pas de vrais problèmes (mais je remets en question les performances de lecture / écriture séquentielle depuis un certain temps).
— 3molo
Mise à jour avec latence et temps d'attente, commençant à soupçonner qu'il y a toujours du temps pour répondre aux demandes et qui priorise le scrub si bas qu'il s'arrête. Tout aperçu est très utile!
— 3molo
Les gommages sont importants pour s'exécuter périodiquement. Attendre que vous ayez un problème pour exécuter un nettoyage demande que ce problème se transforme en perte de données. Les scrubs sont là pour attraper la corruption silencieuse des données (bitrot). Un nettoyage lent ne signifie pas un problème système, juste un pool qui est suffisamment occupé pour ne pas laisser le nettoyage s'accélérer.
— lschweiss
0

Ma réponse arrive un peu tard, mais si ce genre de chose arrive à quelqu'un d'autre, voici mon avis: essayez simplement "dmesg". Dans mon cas, je ne faisais pas de nettoyage, mais je copiais des fichiers sur les disques, et j'entendais clairement que les disques étaient actifs pendant quelques secondes, puis tous s'arrêtaient plus longtemps, puis fonctionnaient à nouveau, etc. Cela était dû à la défaillance d'un contrôleur SATA et dmesg m'a donné toutes les erreurs. Je pensais que c'était un disque défaillant au début, mais j'ai réalisé que c'était en fait le contrôleur.

— jytou
source
-3

Scrub utilise les temps d'arrêt système disponibles, même sur un serveur déchargé, c'est une question de disponibilité. Ram et processeur sont les clés de l'utilisation de scrub, pas le disque. Plus ils sont disponibles, meilleures seront les performances de votre gommage. Cependant, dans ce cas, certainement, mieux vos disques sont disposés, en termes de ZPools, meilleures seront vos performances de scrub.

Donc, si vos performances ont été lentes et que cela semble être le cas, je considérerais ces raisons comme des raisons potentielles.

— user169761
source
1
Je ne vois aucun indicateur que les ressources sont rares.
— 3molo
1
C'est à peu près complètement faux. Le processeur et la RAM n'ont aucun impact sur les opérations de nettoyage (en supposant qu'il y en ait du tout gratuitement). Avoir beaucoup de RAM et de CPU gratuits n'accélèrera pas les opérations de nettoyage. Scrub est limité en regardant les E / S entrantes dans le pool, et non en vérifiant les «temps d'arrêt système disponibles», quel qu'il soit.
— Nex7
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.