web-dev-qa-db-fra.com

Réglages ReadAhead pour LVM, Device-Mapper, RAID logiciel et Périphériques de blocs - Qu'est-ce qui gagne?

J'ai essayé de trouver une réponse directe sur celle-ci et elle s'est avérée insaisissable. Ceci question et sa réponse est proche, mais ne me donne pas vraiment les détails que je voudrais. Commençons par ce que je pense savoir.

Si vous avez un périphérique de bloc standard et que vous exécutez Sudo blockdev --report Vous obtiendrez quelque chose comme ça:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0    500107862016   /dev/sda
rw   256   512  4096       2048    399999238144   /dev/sda1
rw   256   512  1024  781252606            1024   /dev/sda2

Maintenant, vous décidez de changer de valeur par défaut de 256 à 128 en utilisant --setra Sur l'une des partitions et il arrive à tout le périphérique de bloc, comme:

Sudo blockdev --setra 128 /dev/sda1
Sudo blockdev --report
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   128   512  4096          0    500107862016   /dev/sda
rw   128   512  4096       2048    399999238144   /dev/sda1
rw   128   512  1024  781252606            1024   /dev/sda2

Cela donne un sens parfait pour moi - le périphérique de niveau de bloc est l'endroit où le réglage est, pas la partition, donc tout change. De plus, la relation par défaut entre le paramètre RA et l'appareil est logique pour moi, c'est généralement:

RA * sector size (default = 512 bytes)

Par conséquent, les changements que j'ai faits ci-dessus, la taille du secteur par défaut baissera Readahead de 128k à 64k. Tous bien et bien jusqu'à présent.

Cependant, que se passe-t-il lorsque nous ajoutons un raid logiciel, ou LVM et un appareil-mapper? Imaginez que votre rapport ressemble à ceci à la place:

RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0     10737418240   /dev/xvda1
rw   256   512  4096          0    901875499008   /dev/xvdb
rw   256   512  4096          0    108447924224   /dev/xvdj
rw   256   512  4096          0    108447924224   /dev/xvdi
rw   256   512  4096          0    108447924224   /dev/xvdh
rw   256   512  4096          0    108447924224   /dev/xvdg
rw  4096   512  4096          0    433787502592   /dev/md0
rw  4096   512   512          0    429496729600   /dev/dm-0

Dans ce cas, nous avons un périphérique DM-0 mappé DM-0 au-dessus du MD0 créé par MDADM, qui est en fait une bande RAID0 sur les quatre appareils XVDG-J.

Les MD0 et DM-0 ont à la fois des réglages de 4096 pour RA, bien plus haut que les dispositifs de bloc. Donc, quelques questions ici:

  • Comment le paramètre RA est-il passé dans la chaîne de périphérique Virtual Block?
  • DM-0 l'a-t-il attentif à tous parce que c'est le périphérique de bloc de haut niveau que vous accédez?
  • Aurait lvchange -r avoir un impact sur le périphérique DM-0 et ne pas apparaître ici?

S'il est aussi simple que, le paramètre RA du périphérique de bloc virtuel que vous utilisez est transmis, cela signifie-t-il qu'une lecture de DM-0 (ou MD0) se traduira par une lecture de 4 x 4096 RA? (un sur chaque dispositif de bloc). Si tel est le cas, cela signifierait que ces paramètres explosent la taille de la ReadAhead dans le scénario ci-dessus.

Ensuite, en termes de détermination de ce que le cadre Readahead fait réellement:

Qu'utilisez-vous, équivalent à la taille du secteur ci-dessus pour déterminer la valeur réelle ReadAhead pour un périphérique virtuel:

  • La taille de la bande de la raid (pour MD0)?
  • Une autre taille de taille équivalente?
  • Est-ce configurable et comment?
  • Est-ce que le FS joue-t-il une pièce (je suis principalement intéressé par EXT4 et XFS)?
  • Ou, s'il est simplement passé, est-ce simplement le paramètre RA du périphérique de niveau supérieur multiplié par la taille du secteur des périphériques de bloc réels?

Enfin, il y aurait une relation privilégiée entre la taille de la bande et le paramètre RA (par exemple)? Ici, je pense que si la bande est le plus petit élément qui va être tiré du périphérique RAID, vous ne voudrez pas idéalement qu'il soit nécessaire de disposer de 2 accès à un disque au service que l'unité minimale de données et voudrait faire le RA assez grand pour répondre à la demande avec un seul accès.

linuxlvmsoftware-raidmdblock-device
26
Adam C

Connaître la réponse plus difficile à expliquer afin que je le ferai par exemple. Dites-ce que vous avez 3 périphériques de blocs, vous avez défini votre RA à dire 4 (4 * 512 octets) en supposant que le secteur standard. Si vous deviez dire, utilisez un schéma RAID-5 à l'aide des 3 disques, toute lecture que même touchée une bande sur un disque unique composerait le PR par le facteur que vous définissez initialement le périphérique de bloc Ra à. Donc, si vous avez lu exactement les 3 disques, votre RA effectif serait de 12 * 512 octets. Cela peut être aggravé par le règlement RA aux différents niveaux, par exemple MD ou LVM. En règle générale, si mon application bénéficie de RA, je l'ai définie sur la couche la plus élevée possible afin que je ne composais pas le RA inutile. Je commence ensuite le système de fichiers sur le secteur 2049 et compenser chaque secteur d'un numéro divisible d'ici 8. Je suis peut-être bien sur ce que vous demandez, mais c'est mon 2 ¢.

4
Bill Clark

C'est pour l'explication. J'ai fait des tests avec une installation RAID et LVM pour prouver que vous avez raison:

https://fatalfailure.wordpress.com/2017/05/13/where-a-se-readaead-lvm-raid-devices-device-mapper-Block-devices

Celui qui compte est celui que l'OS utilise

0
victorgp