Sui server DL380p gen8 che utilizzano XFS su LVM su raid 1 + 0 con 6 dischi, un carico di lavoro identico comporta un aumento di dieci volte delle scritture su disco su RHEL 6 rispetto a RHEL 5, rendendo le applicazioni inutilizzabili.

Nota che non sto cercando di ottimizzare il sistema co6 il più possibile, ma di capire perché il co6 si comporta in modo così diverso e di risolverlo.

vmstat / iostat

Abbiamo una configurazione di replica di MySQL, usando mysql 5.5. Gli slave Mysql sui server gen8 che utilizzano RHEL 6 come SO funzionano male, l'ispezione con vmstat e iostat mostra che questi server svolgono un'attività dieci volte superiore alla pagina e dieci volte la quantità di scritture sul sottosistema del disco. blktrace mostra che queste scritture non sono iniziate da mysql, ma dal kernel.

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

E su Centos 6 un aumento di dieci volte delle scritture su paging e su disco:

[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

Restringendo

Server Gen 8 che utilizzano RHEL 5 e server Gen 7 che utilizzano RHEL 5 o 6 non mostrano questo problema. Inoltre, RHEL 6 con ext3 come filesystem invece del nostro xfs predefinito non mostra il problema. Il problema sembra essere davvero a metà tra XFS, hardware gen8 e centos 6. Anche RHEL 6 mostra il problema.

Modifica 29/04: abbiamo aggiunto qlogic HBA alla macchina G8. L'uso di XFS su memoria Fibre Channel non mostra il problema. Quindi è sicuramente da qualche parte nell'interazione tra xfs / hpsa / p420i.

XFS

Il nuovo xfs in rhel 8 sembra essere in grado di rilevare la larghezza di banda sottostante, ma solo sui controller p420i che utilizzano il driver hpsa, non sui controller p410i che utilizzano cciss.

output 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 sono entrambi 0 in tutte le impostazioni contrassegnate come OK sopra. Sembra che non siamo in grado di cambiarlo, sia in mkfs che con l'opzione noalign mount. Inoltre non sappiamo se questa sia la causa.

hugepages

Altre persone che hanno problemi con XFS su rhel 6, affermano che disabilitare gli hugepage e soprattutto gli hugepage trasparenti può essere utile. Abbiamo disabilitato entrambi, il problema non è andato via.

Abbiamo già provato e osservato molte cose, nessuna delle seguenti ha aiutato:

• Utilizzo di numactl per influenzare le allocazioni di memoria. Abbiamo notato che g7 e g8 hanno un diverso layout numa, nessun effetto è stato visto
• I kernel più recenti (nuovi come 3.6) non sembravano risolvere questo problema. Nemmeno con fedora 17.
• iostat non segnala un aumento di dieci volte nelle transazioni di scrittura, ma solo nel numero di byte scritti
• L'uso di scheduler I / O diversi non ha alcun effetto.
• Montare il relativo filesystem noatime / nobarrier / nopdiratime non ha aiutato
• La modifica di / proc / sys / vm / dirty_ratio non ha prodotto alcun effetto
• Ciò accade sia su sistemi basati su CPU 2640 e 2670
• hpsa-3.2.0 non risolve il problema

XFS ed EL6 sono caduti in uno stato brutto ... Per il momento ho abbandonato XFS sui sistemi EL6 a causa di diverse funzionalità / modifiche a monte che sono scivolate nel kernel di Red Hat ...

Questa è stata una sorpresa e ha causato un po 'di panico: perché i miei filesystem XFS improvvisamente consumano più spazio e sono pieni di file sparsi?

Da novembre 2012, la versione XFS viene spedita in kernel più recenti rispetto a 2.6.32-279.11.1.el6un fastidioso problema di carico e prestazioni derivante da Red Hat Bugzilla 860787 . Da allora, ho avuto prestazioni imprevedibili e code di esecuzione più elevate rispetto alla media.

Per i nuovi sistemi, sto usando ZFS o semplicemente ext4. Per i sistemi più vecchi, li sto congelando a 2.6.32-279.11.1.el6.

Prova a tornare a quella versione con:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Oltre a quanto sopra, a causa del tipo di controller RAID che stai utilizzando, le ottimizzazioni tipiche sono nell'ordine:

Monta i tuoi filesystem XFS noatime. Dovresti anche sfruttare il framework Tuned con:

tuned-adm profile enterprise-storage

per impostare readahead, nobarrier e I / O ascensore su una buona base.

Modificare:

Ci sono molti consigli sull'ottimizzazione del filesystem XFS. Ho usato il filesystem esclusivamente negli ultimi dieci anni e ogni tanto ho dovuto regolare i parametri man mano che si verificavano cambiamenti alla base del sistema operativo. Non ho riscontrato un drastico calo delle prestazioni come il tuo, ma non utilizzo LVM.

Penso che sia irragionevole aspettarsi che EL5 si comporti allo stesso modo di EL6 , data la diversa generazione del kernel, impostazioni predefinite compilate, scheduler, pacchetti, ecc.

Cosa avrei io fare a questo punto ??

• Vorrei esaminare i parametri mkfs.xfs e come stai costruendo i sistemi. Stai utilizzando il partizionamento XFS durante l'installazione o la creazione delle partizioni dopo il fatto? Faccio la creazione del filesystem XFS dopo l'installazione del sistema operativo principale perché ho maggiore flessibilità nei parametri indicati.

• I miei parametri di creazione di mkfs.xfs sono semplici: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1ad esempio.

• Le mie opzioni di mount sono: noatime,logbufs=8,logbsize=256k,nobarrierconsentirei la preallocazione dinamica XFS di funzionare in modo nativo e non vincolarla come hai fatto qui. Le mie prestazioni sono migliorate con esso.

• Quindi non uso LVM . Soprattutto su RAID hardware ... Soprattutto su controller HP Smart Array, dove ci sono alcune funzioni simili a LVM native del dispositivo. Tuttavia, usando LVM, non hai accesso afdisk per la creazione di partizioni non elaborate. Una cosa che è cambiata da EL5 a EL6 è l'allineamento della partizione nell'installer e passa a fdisk per impostare il settore di partenza su un limite del cilindro.

• Assicurarsi di utilizzare i controller e le unità HP Smart Array al livello di revisione corrente. A quel punto, ha senso aggiornare l' intero server all'attuale Service Pack HP per la revisione del firmware ProLiant . Questo è un DVD avviabile che aggiornerà tutti i componenti rilevati nel sistema.

• Verificherei le impostazioni del controller RAID. Incolla l'output di hpacucli ctrl all show config detail. Ecco il mio. Volete un rapporto di cache distorto tra scritture e letture. 75:25 è la norma. La dimensione di strip predefinita di 256 KB dovrebbe andare bene per questa applicazione.

• Potrei provare questo senza LVM.

• Quali sono i tuoi sysctl.confparametri?

Abbiamo riscontrato un problema simile e abbiamo scoperto che è dovuto alla modifica della versione del registro XFS. I log della versione 2 onorano il set di larghezza della striscia utilizzato con mkfs.xfs. Se fai molto fsync, la tua carta incursione non può più falsificare le scritture dei log. Puoi testarlo formattando la partizione senza alcuna impostazione di larghezza (non fa alcuna differenza con RAID 1 + 0). Puoi verificarlo con blktrace / seekwatcher per vedere se comporta un sacco di aggiornamento del registro.