Pourquoi un temps d'attente plus long pour le périphérique multichemin DM que le périphérique sous-jacent?

Nous avons un serveur basé sur CentOS 6.4 attaché au stockage Hitachi HNAS 3080 et avons observé que le noyau remonte le système de fichiers en mode lecture seule:

16 mai 07:31:03 Noyau GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): erreur: remontage du système de fichiers en lecture seule

Cela s'est produit après plusieurs erreurs d'E / S et tous les chemins vers le périphérique seraient en panne:

16 mai 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: chemins actifs restants: 0

J'ai regardé les journaux sar et je peux voir quelques temps d'attente très importants (2 secondes):

07:40:00       dev8-0     17.91    112.04     98.03     11.73      0.00      0.20      0.07      0.12
07:40:00      dev8-16      0.23      1.85      0.00      8.00      0.00      3.71      3.71      0.09
07:40:00      dev8-32     91.50   8338.76   5292.93    148.98      8.38     91.60      9.76     89.35
07:40:00     dev252-0     91.27   8336.91   5292.93    149.34     17.79    194.88      9.79     89.38
07:40:00     dev252-1    674.80   8168.16   5292.93     19.95   1473.53   2183.60      1.32     88.98

La durée entre 07: 30: 00-07: 40: 00 se produit au moment où le système de fichiers a été monté en lecture seule. Cependant, même dans des conditions normales, une observation répétée est que le temps d'attente pour les dispositifs sous-jacents est beaucoup plus court que celui du dispositif à trajets multiples. Par exemple:

00:00:00          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
00:10:00       dev8-0     19.27    129.41     78.61     10.80      0.01      0.27      0.16      0.32
00:10:00      dev8-16      0.23      1.80      0.00      8.00      0.00      0.86      0.84      0.02
00:10:00      dev8-32     94.88  10285.16   3363.48    143.86      3.39     35.76      6.83     64.82
00:10:00     dev252-0     94.65  10283.34   3363.48    144.18      3.64     38.47      6.86     64.89
00:10:00     dev252-1    435.06  10087.12   3363.48     30.92    118.42    272.21      1.47     64.12

dev8-0 se trouve être le disque local, tandis que dev8-16 ( /dev/sdb) et dev8-32 ( /dev/sdc) sont les disques sous-jacents de dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) est une partition unique couvrant l'ensemble du périphérique à chemins multiples. Voici la sortie de multipath -ll:

mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sdb 8:16 active ready running

Pourquoi le temps d'attente devrait-il /dev/mapper/mpathap1être tellement plus élevé que celui de /dev/mapper/mpathaou même /dev/sdbou /dev/sdc?

performance iowait device-mapper

— pdp
source

Il semble remarquable que, apparemment, de nombreuses fusions de demandes se produisent sur le chemin de /dev/mapper/mpathap1à /dev/mapper/mpatha. C'est également la couche où la plupart du awaittemps semble être ajoutée. Pouvez-vous vérifier dans quels ascenseurs sont utilisés /sys/block/mpathap1/queue/scheduleret /sys/block/mpatha/queue/scheduler, éventuellement, le changer deadlineou le noopcomparer?

— the-wabbit

Le planificateur d'E / S pour mpatha( /sys/block/dm-0/queue/scheduler) est noopet celui pour mpathap1( /sys/block/dm-1/queue/scheduler) est none.

— pdp

Je soupçonne fortement que l'algorithme de mise en file d'attente / fusion du planificateur est responsable du retard. Je voudrais échanger cfq des périphériques sous-jacents pour noop ou délai juste pour voir si cela change quelque chose. Cependant, cela ne sera probablement pas lié à votre problème tous les chemins vers le bas.

— the-wabbit

FWIW, j'ai observé le même type de comportement sur d'autres types de périphériques de mappage de périphériques - en particulier avec les pools NSS . Les dmécritures fusionnables ont une attente (et des files d'attente plus longues) sur le périphérique que sur le périphérique physique sous-jacent, tandis que les demandes de lecture et les écritures sans aucune fusion ne sont généralement pas affectées. Je ne sais pas encore s'il s'agit simplement d'une erreur de présentation en raison de la façon dont les attentes sont calculées ou des temps de réponse réellement prolongés en raison de la nature de l'algorithme de mise en file d'attente / fusion.

— le-wabbit du

L'un des scripts Systemtap IO pourrait éventuellement vous fournir des informations supplémentaires sur ce qui se passe. io_submit.stp, ioblktime.stp et biolatency-nd.stp peuvent être de bons points de départ.

— Kassandry

Comme le suggère l'utilisateur the-wabbit, une fusion de demandes est en cours. Vous pouvez voir que dans la colonne avgrq-sz, la taille moyenne des requêtes - qui montre une augmentation significative.

Maintenant, «attendre» est le temps passé dans la file d'attente plus le temps passé à traiter ces demandes. Si une petite demande, appelons-la «x», est fusionnée avec quelques autres demandes (y et z, émises après x), alors x

attendre dans la file d'attente pour être fusionné avec y
attendez dans la file d'attente pour être fusionné avec z
attendez que (x, y, z) soit terminé

Cela aura évidemment un impact négatif sur la statistique d'attente, principalement en raison de la façon dont l'attente est calculée, sans réellement signifier un problème en soi.

Jetons maintenant un œil à / dev / sdb (dev8-16). Saviez-vous que vous n'utilisez pas ce chemin? Vous avez deux groupes de priorité dans votre configuration à chemins multiples, l'un est

status = activé

et est sur

statut = actif

Vous avez probablement

basculement path_grouping_policy

dans votre configuration (qui est la valeur par défaut).

Si vous souhaitez éviter les erreurs d'E / S dans le cas où les deux chemins sont en panne, vous pouvez essayer:

        comporte "1 queue_if_no_path"

dans votre multipath.conf

Maintenant, la vraie question demeure, pourquoi les deux chemins descendent-ils?

— esprit distant
source