3 votes

iostat - le périphérique dm-0 montre des latences beaucoup plus élevées que sdX

Nous exécutons des machines virtuelles sous linux (Centos 5.x) au-dessus de vmware vsphere 5.5. Je surveille la latence des disques à l'aide d'iostat, en particulier la colonne d'attente, mais je constate des résultats étranges avec le mappeur de périphériques/LVM par rapport aux disques "physiques" qui soutiennent LVM.

Voici un ensemble de résultats de iostat -x 5 sur l'une de nos machines virtuelles relativement actives. La VM en question a deux disques, sda avec une partition /boot, et sdb comme disque principal avec / sur sdb2. Alors que iostat montre des latences de ~20-40ms pour l'attente pour le périphérique sdb2 (le seul périphérique/partition soutenant mon volgroup / dm-0), iostat pour dm-0 montre 100+ms d'attente.

Ma question est la suivante : quelle statistique est "correcte" ici, en ce qui concerne les latences réelles que le système voit ? Est-ce qu'il voit les ~20ms indiqués pour le disque "physique" sdb, ou est-ce qu'il voit vraiment 100+ms à partir de dm-0, peut-être à cause de certains problèmes d'alignement / etc. qui surviennent lorsque LVM est impliqué ? C'est étrange car parfois les statistiques correspondent assez bien, d'autres fois elles sont très éloignées - par exemple, dans le bloc de sortie iostat ci-dessous, sdb2 montre 419 IOPS en écriture, alors que dm-0 montre 39k IOPS en écriture.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.78    0.00    8.42   39.07    0.00   46.73

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb              15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2             15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
dm-0              0.00     0.00 761.33 39720.67 64120.00 317765.33     9.43  4933.92  121.88   0.02 100.07

Mise à jour : J'ai fait quelques lectures supplémentaires, y compris les liens dans la réponse de Gene ci-dessous. Je sais qu'il y a beaucoup de variables en jeu (virtualisation, système de fichiers en bloc, etc.), mais cette partie semble réglée, selon nos fournisseurs et les meilleures pratiques de VMware, et les performances sont en fait très bonnes. Je ne vois vraiment les choses que du point de vue de "l'intérieur de la VM".

Sur cette note, je soupçonne qu'il y a un problème avec notre partition + alignement LVM :

GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483647s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End          Size         Type     File system  Flags
 1      63s       4192964s     4192902s     primary  linux-swap   boot
 2      4192965s  2097151999s  2092959035s  primary               lvm

~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb2
  VG Name               VolGroup00
  PV Size               998.00 GB / not usable 477.50 KB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              31936
  Free PE               0
  Allocated PE          31936
  PV UUID               tk873g-uSZA-JaWV-R8yD-swXg-lPvM-dgwPQv

En lisant sur l'alignement, il semble que votre secteur de départ devrait être divisible par 8, donc vous vous alignez sur une frontière de 4kb, avec la taille de secteur standard de 512b. Il semble que LVM soit capable de s'aligner automatiquement lorsque vous l'appliquez à un disque entier, mais puisque nous divisons d'abord le disque, et que nous faisons ensuite de notre partition /dev/sdb2 un périphérique physique à utiliser par LVM, je ne suis pas sûr qu'il soit capable de calculer un décalage dans ce cas. Par http://linux.die.net/man/5/lvm.conf le paramètre data_alignment_offset_detection : "S'il est défini à 1, et que votre noyau fournit des informations de topologie dans sysfs pour le volume physique, le début de la zone de données alignées du volume physique sera décalé par l'alignement_offset exposé dans sysfs." C'est Centos5, et je ne vois aucune de ces informations exposées dans sysfs, seulement sur nos vm Centos6 et plus récents, donc il pourrait ne pas être en mesure de s'aligner correctement sur un volume physique.

J'ai trouvé ce livre blanc de Netapp sur l'alignement des partitions des VM. http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc=us Plus précisément, il y a de bonnes informations dans la section 4.5, page 29, sur le partitionnement correct d'une VM pour un alignement correct avec LVM. Je vais suivre ces conseils pour que nos nouvelles VM soient alignées correctement.

Cela semble pouvoir provoquer ce comportement. Quelqu'un ayant plus de connaissances/expérience peut-il le confirmer ?

3voto

freddie montana Points 21

Il n'y a pas de réponse facile puisque la virtualisation est impliquée. Vous avez un disque virtuel situé au-dessus d'un système de fichiers au-dessus d'un périphérique de bloc présenté à un invité virtuel qui a son propre pilote présentant un périphérique de bloc à LVM. Je ne sais pas avec certitude si cela entraînerait nécessairement une différence aussi importante, mais c'est possible.

Au-delà de ça...

LVM ajoute des frais généraux, il y aura donc une différence. Si votre LVM et vos périphériques de bloc ne sont pas alignés correctement, cela peut également être un facteur contributif.

L'alignement n'est pas un sujet simple qui peut être abordé dans un cadre tel que celui-ci. Le mieux que je puisse faire est de vous renvoyer à quelques documents, peut-être y trouverez-vous plus de réponses :

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X