web-dev-qa-db-fra.com

Tuning ZFS Scrubbing, 141kb / s en cours d'exécution pendant 15 jours

Un système assez élévateur de base en cours d'exécution + rayures sur 7,2k DRP SAS Disks, non particulièrement chargée. Pas de dédicace, compression sur tous les jeux de données. Le gommage est en cours de course pendant 15 jours à la vitesse d'un escargot mort. Existe-t-il une certaine optimisation qui doit être effectuée ou peut-être en raison d'une HW défectueuse?

  • 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 j'exécute cette fois

# 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 est écrite. Entre celles-ci écrit, il n'y a essentiellement aucune lecture ou écrit.

                          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
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Les iostats me disent-ils que je passe plus de temps à attendre le disque que je devrais avoir à devoir? Spécifiquement 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 du haut?

# 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é un peu de peau qui a fait peu de différence. zfs_top_maxinflight défini sur 127, zfs_scrub_delay à 0 et zfs_scan_idle à 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é-mdb Tweak, remarquez 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, remarquez la colonne B%, 80-85% heure à attendre occupé

$ 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
zfsnexenta
14
3molo

Les opérations de gommage ZFS opèrent sur des principes assez mûrs de cerveau. Plus particulièrement, il ne dépense que du temps de nettoyer quand il n'y a rien d'autre. Si vous piquez une piscine avec un peu d'accès à des données à une base assez constante, le gommage va effectivement mourir de faim et faire presque rien.

Les tunables à explorer, avec mes notes rapides sur ce que ça fait (je l'ai examiné de cette dernière dans ce temps):

  • zfs_scan_idle - Si les E/S de l'utilisateur se présentent dans ces nombreuses tiques d'horloge, délais écrans d'E/S par zfs_scrub_delay clock ticks
  • zfs_scrub_delay - Combien d'horloge ticks pour retarder le fonctionnement du gommage si elles sont déclenchées par zfs_scan_idle
  • zfs_top_maxinflight - Nombre maximum de gommage I/O par niveau supérieur VDEV
  • zfs_scrub_limit - Nombre maximum de gommage E/S par feuille VDEV
  • zfs_scan_min_time_ms - Mme minimale à dépenser par TXG sur les opérations de gommage
  • zfs_no_scrub_io - pas de notes
  • zfs_no_scrub_prefetch - Aucune notes, le nom semble impliquer de ne pas causer de préfetche sur les ops de gommage

Tous ces éléments sont modifiables à la volée en utilisant "ECHO [TONALLABLE]/W0T [NUMBER]" "pour changer," ECHO [TONALLABLE]/D "pour afficher le paramètre actuel (que je recommande de faire avant de changer).

Donc, en théorie, et en pratique générale, si vous le souhaitez, disez, changez zfs_scan_idle jusqu'à 10 (ou 1 - ou 0, si elle prend en charge cela, il faudrait vérifier le code) et zfs_scrub_delay jusqu'à 1 (ou 0, si Il prend en charge cela), et si votre paramètre TXG_SYNCTIME_MS est 5000 ou plus peut-être modifier un peu de zfs_scan_min_time_ms up un peu, il devrait devenir beaucoup plus agressif pour faire des opérations de gommage, même avec un certain niveau d'E/S de l'utilisateur.

Dans votre cas spécifique, le% B et ASVC_T signalé impliquent une charge de travail très aléatoire de lecture très aléatoire (les disques de filage devraient faire mieux que cela s'il est vraiment séquentiel), et vous avez déjà fait les choses "faciles" comme expliqué ci-dessus . Donc, j'allumais d'abord zfs_no_scrub_prefetch pour désactiver la préfecture des opérations de gommage, juste pour voir si cela a aidé. Si aucune joie, selon la version de Nexenta, vous êtes sur vous - vous pouvez exécuter 30/5, 5/1 ou 10/5 (c'est sténographique que nous utilisons pour les paramètres de zfs_txg_timeout et (ZFS_TXG_SYNCTIME_MS * 1000)). Modifier zfs_txg_timeout sur 10 et zfs_txg_synctime_ms à 5000, puis essayez de monter zfs_scan_min_time_ms à 3000 ou 4000. Cela indique à ZFS, cela peut dépenser beaucoup plus longtemps sur les écrans, par rapport aux paramètres par défaut sur les installations de Nexentastor plus anciennes qui utilisent 5/1 comme étant les paramètres par défaut - mais Attention, cela peut affamer les E/S normal si les réglages de retard ont également été définis sur 0!

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

11
Nex7

Ma réponse vient un peu tard, mais si ce genre de chose arrive à quiconque, voici mon principe: essayez simplement "dmesg". Dans mon cas, je ne faisais pas un gommage, mais je copie des fichiers vers les disques et j'entendais clairement que les disques sont actifs pendant quelques secondes, puis tous s'arrêtant pendant plus longtemps, et encore de nouveau travailler et ainsi de suite. Cela était dû à l'échec d'un contrôleur SATA et de DMESG m'a donné toutes les erreurs. Je pensais que c'était un disque défaillant au début, mais je me suis rendu compte que c'était en réalité le contrôleur.

0
jytou