Sur les serveurs DL380p gen8 utilisant XFS au-dessus de LVM au-dessus du raid 1 + 0 avec 6 disques, une charge de travail identique entraîne une multiplication par dix des écritures sur disque sur RHEL 6 par rapport à RHEL 5, rendant les applications inutilisables.

Notez que je ne cherche pas à optimiser le système co6 autant que possible, mais à comprendre pourquoi le co6 se comporte si différemment et à résoudre ce problème.

vmstat / iostat

Nous avons une configuration de réplication MySQL, utilisant mysql 5.5. Les esclaves Mysql sur les serveurs gen8 utilisant RHEL 6 comme système d'exploitation fonctionnent mal, l'inspection avec vmstat et iostat montre que ces serveurs font dix fois l'activité de sortie de page et dix fois la quantité d'écritures sur le sous-système de disque. blktrace montre que ces écritures ne sont pas initiées par mysql, mais par le noyau.

Centos 5:

[dkaarsemaker@co5 ~]$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0     12 252668 102684 10816864    0    0     8   124    0    0  9  1 90  0  0
 1  0     12 251580 102692 10817116    0    0    48  2495 3619 5268  6  1 93  0  0
 3  0     12 252168 102692 10817848    0    0    32  2103 4323 5956  6  1 94  0  0
 3  0     12 252260 102700 10818672    0    0   128  5212 5365 8142 10  1 89  0  0

[dkaarsemaker@co5 ~]$ iostat 1
Linux 2.6.18-308.el5 (bc290bprdb-01.lhr4.prod.booking.com)  02/28/2013

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.74    0.00    0.81    0.25    0.00   90.21

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      277.76       399.60      5952.53 2890574849 43058478233
cciss/c0d0p1      0.01         0.25         0.01    1802147      61862
cciss/c0d0p2      0.00         0.01         0.00     101334      32552
cciss/c0d0p3    277.75       399.34      5952.52 2888669185 43058383819
dm-0             32.50        15.00       256.41  108511602 1854809120
dm-1            270.24       322.97      5693.34 2336270565 41183532042

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.49    0.00    0.79    0.08    0.00   91.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      300.00        32.00      4026.00         32       4026
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    300.00        32.00      4026.00         32       4026
dm-0              0.00         0.00         0.00          0          0
dm-1            300.00        32.00      4026.00         32       4026

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.25    0.00    0.46    0.21    0.00   95.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      507.00       160.00     10370.00        160      10370
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    507.00       160.00     10370.00        160      10370
dm-0              0.00         0.00         0.00          0          0
dm-1            507.00       160.00     10370.00        160      10370

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.33    0.00    0.50    0.08    0.00   94.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      318.00        64.00      4559.00         64       4559
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    319.00        64.00      4561.00         64       4561
dm-0              0.00         0.00         0.00          0          0
dm-1            319.00        64.00      4561.00         64       4561

Et sur Centos 6, une multiplication par dix des écritures paginées et sur disque:

[root@co6 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 361044  52340 81965728    0    0    19  1804   36  110  1  1 98  0  0  
 0  0      0 358996  52340 81965808    0    0   272 57584 1211 3619  0  0 99  0  0  
 2  0      0 356176  52348 81966800    0    0   240 34128 2121 14017  1  0 98  0  0 
 0  1      0 351844  52364 81968848    0    0  1616 29128 3648 3985  1  1 97  1  0  
 0  0      0 353000  52364 81969296    0    0   480 44872 1441 3480  1  0 99  0  0  

[root@co6 ~]# iostat 1
Linux 2.6.32-279.22.1.el6.x86_64 (bc291bprdb-01.lhr4.prod.booking.com)  02/28/2013  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.08    0.00    0.67    0.27    0.00   97.98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             373.48      1203.02    115203.05   11343270 1086250748
dm-0             63.63        74.92       493.63     706418    4654464
dm-1            356.48      1126.72    114709.47   10623848 1081596740

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.19    0.06    0.00   99.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             330.00        80.00     77976.00         80      77976
dm-0              0.00         0.00         0.00          0          0
dm-1            328.00        64.00     77456.00         64      77456

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.00    0.19    0.63    0.00   98.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             570.00      1664.00    128120.00       1664     128120
dm-0              0.00         0.00         0.00          0          0
dm-1            570.00      1664.00    128120.00       1664     128120

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.66    0.00    0.47    0.03    0.00   98.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             317.00       448.00     73048.00        448      73048
dm-0             34.00         0.00       272.00          0        272
dm-1            309.00       448.00     72776.00        448      72776

Affiner

Les serveurs Gen 8 utilisant RHEL 5 et les serveurs Gen 7 utilisant RHEL 5 ou 6 ne présentent pas ce problème. De plus, RHEL 6 avec ext3 comme système de fichiers au lieu de notre xfs par défaut ne montre pas le problème. Le problème semble vraiment se situer entre XFS, le matériel gen8 et centos 6. RHEL 6 montre également le problème.

Edit 29/04: nous avons ajouté le qlogic HBA à la machine G8. L'utilisation de XFS sur le stockage Fibre Channel ne montre pas le problème. Donc, c'est certainement quelque part dans l'interaction entre xfs / hpsa / p420i.

XFS

Le nouveau xfs de rhel 8 semble être capable de détecter la largeur de bande sous-jacente, mais uniquement sur les contrôleurs p420i utilisant le pilote hpsa, et non sur les contrôleurs p410i utilisant cciss.

Sortie xfs_info:

[root@co6 ~]# xfs_info /mysql/bp/
meta-data=/dev/mapper/sysvm-mysqlVol isize=256    agcount=16, agsize=4915136 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642176, imaxpct=25
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sunit / swidth sont tous les deux 0 dans toute la configuration marquée comme OK ci-dessus. Nous semblons être incapables de changer cela, soit dans mkfs, soit avec l'option de montage noalign. Nous ne savons pas non plus si c'est la cause.

Hugepages

D'autres personnes ayant des problèmes XFS sur rhel 6 disent que la désactivation d'énormes pages, et en particulier d'énormes pages transparentes, peut être bénéfique. Nous avons désactivé les deux, le problème n'a pas disparu.

Nous avons déjà essayé et observé beaucoup de choses, aucune des choses suivantes n'a aidé:

• Utilisation de numactl pour influencer les allocations de mémoire. Nous avons remarqué que g7 et g8 ont une disposition numa différente, aucun effet n'a été observé
• Les noyaux plus récents (aussi récents que 3.6) ne semblaient pas résoudre ce problème. Pas plus que l'utilisation de fedora 17.
• iostat ne signale pas une multiplication par dix des transactions d'écriture, uniquement en nombre d'octets écrits
• L'utilisation de différents planificateurs d'E / S n'a aucun effet.
• Le montage du système de fichiers approprié noatime / nobarrier / nopdiratime n'a pas aidé
• La modification de / proc / sys / vm / dirty_ratio n'a eu aucun effet
• Cela se produit à la fois sur les systèmes basés sur les processeurs 2640 et 2670
• hpsa-3.2.0 ne résout pas le problème

XFS et EL6 sont tombés dans un état laid ... J'ai abandonné XFS sur les systèmes EL6 pour le moment en raison de plusieurs fonctionnalités / changements en amont se glissant dans le noyau Red Hat ...

Celui-ci a été une surprise et a provoqué une certaine panique: pourquoi mes systèmes de fichiers XFS consomment-ils soudainement plus d'espace et pleins de fichiers épars?

Depuis novembre 2012, la version XFS est livrée dans des noyaux plus récents que ceux 2.6.32-279.11.1.el6ayant un problème de charge et de performances gênant provenant de Red Hat Bugzilla 860787 . Depuis lors, j'ai eu des performances imprévisibles et des files d'attente d'exécution plus élevées que la moyenne.

Pour les nouveaux systèmes, j'utilise ZFS ou simplement ext4. Pour les anciens systèmes, je les fige 2.6.32-279.11.1.el6.

Essayez de revenir à cette version avec:

yum install kernel-2.6.32-279.11.1.el6.x86_64

En plus de ce qui précède, en raison du type de contrôleur RAID que vous utilisez, les optimisations typiques sont en ordre:

Montez vos systèmes de fichiers XFS noatime. Vous devez également tirer parti du cadre Tuned avec:

tuned-adm profile enterprise-storage

pour définir la lecture anticipée, la nobarrier et l'ascenseur d'E / S sur une bonne ligne de base.

Éditer:

Il existe de nombreuses recommandations concernant l'optimisation du système de fichiers XFS. J'ai utilisé le système de fichiers exclusivement pendant la dernière décennie et j'ai parfois dû ajuster des paramètres à mesure que des modifications sous-jacentes du système d'exploitation se produisaient. Je n'ai pas connu de baisse spectaculaire des performances comme la vôtre, mais je n'utilise pas non plus LVM.

Je pense qu'il est déraisonnable de s'attendre à ce que EL5 agisse de la même manière que EL6 , étant donné la génération différente du noyau, les valeurs par défaut compilées, les planificateurs, les packages, etc.

Que ferais- je à ce stade ??

• J'examinerais les paramètres mkfs.xfs et comment vous construisez les systèmes. Utilisez-vous le partitionnement XFS pendant l'installation ou créez-vous les partitions après coup? Je fais la création du système de fichiers XFS après l'installation du système d'exploitation principal parce que j'ai plus de flexibilité dans les paramètres donnés.

• Mes paramètres de création mkfs.xfs sont simples: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1par exemple.

• Options ma monture sont: noatime,logbufs=8,logbsize=256k,nobarrierje permettre à la préallocation dynamique de XFS afin de fonctionner en mode natif et non comme contraignent que vous avez ici. Mes performances se sont améliorées avec.

• Je n'utilise donc pas LVM . Surtout au-dessus du RAID matériel ... Surtout sur les contrôleurs HP Smart Array, où il existe des fonctions de type LVM natives de l'appareil. Cependant, en utilisant LVM, vous n'avez pas accès à fdiskla création de partition brute. Une chose qui est passée de EL5 à EL6 est l'alignement de la partition dans le programme d'installation et passe à fdisk pour définir le secteur de départ sur une limite de cylindre.

• Assurez-vous que vous exécutez vos contrôleurs et lecteurs HP Smart Array au niveau de révision actuel. À ce stade, il est logique de mettre à jour l' intégralité du serveur vers la version actuelle du micrologiciel HP Service Pack pour ProLiant . Il s'agit d'un DVD amorçable qui mettra à niveau tous les composants détectés du système.

• Je vérifierais les paramètres du contrôleur RAID. Collez la sortie de hpacucli ctrl all show config detail. Voici la mienne. Vous voulez un rapport de cache biaisé entre les écritures et les lectures. 75:25 est la norme. La taille de bande par défaut de 256 Ko devrait convenir à cette application.

• J'essaierais potentiellement cela sans LVM.

• Quels sont vos sysctl.confparamètres?

Nous avons eu le même problème et avons découvert qu'il était dû au changement de version du journal XFS. Les journaux de la version 2 respectent l'ensemble de largeur de bande utilisé avec mkfs.xfs. Si vous faites beaucoup de fsync, votre carte de raid ne peut plus simuler ces écritures de journaux. Vous pouvez le tester en formatant la partition sans aucun paramètre swidth (cela ne fait aucune différence avec RAID 1 + 0). Vous pouvez vérifier cela avec blktrace / seekwatcher pour voir si cela implique beaucoup de mise à jour du journal.