En los servidores DL380p gen8 que usan XFS en la parte superior de LVM en la incursión 1 + 0 con 6 discos, una carga de trabajo idéntica da como resultado un aumento de diez veces en las escrituras en disco en RHEL 6 en comparación con RHEL 5, lo que hace que las aplicaciones sean inutilizables.

Tenga en cuenta que no estoy buscando optimizar el sistema co6 tanto como sea posible, sino entender por qué co6 se comporta de manera tan diferente y resolverlo.

vmstat / iostat

Tenemos una configuración de replicación MySQL, usando mysql 5.5. Los esclavos Mysql en servidores gen8 que usan RHEL 6 como SO funcionan mal, la inspección con vmstat e iostat muestra que estos servidores realizan diez veces la actividad de salida de página y diez veces la cantidad de escrituras en el subsistema de disco. blktrace muestra que estas escrituras no son iniciadas por mysql, sino por el núcleo.

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

Y en Centos 6, un aumento de diez veces en paginado y escrituras en 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

Estrechándose

Los servidores Gen 8 que usan RHEL 5 y los servidores Gen 7 que usan RHEL 5 o 6 no muestran este problema. Además, RHEL 6 con ext3 como sistema de archivos en lugar de nuestro xfs predeterminado no muestra el problema. El problema realmente parece estar en algún lugar entre XFS, hardware gen8 y centos 6. RHEL 6 también muestra el problema.

Edición 29/04: agregamos qlogic HBA en la máquina G8. El uso de XFS en el almacenamiento del canal de fibra no muestra el problema. Así que definitivamente está en algún lugar de la interacción entre xfs / hpsa / p420i.

XFS

El xfs más nuevo en rhel 8 parece ser capaz de detectar el ancho de banda subyacente, pero solo en los controladores p420i que usan el controlador hpsa, no en los controladores p410i que usan cciss.

Salida 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 son ambos 0 en toda la configuración marcada como OK arriba. Parece que no podemos cambiar esto, ya sea en mkfs o con la opción de montaje noalign. Tampoco sabemos si esta es la causa.

Enormes páginas

Otras personas que tienen problemas de XFS en rhel 6 dicen que deshabilitar las páginas grandes, y especialmente las páginas grandes transparentes, puede ser beneficioso. Desactivamos ambos, el problema no desapareció.

Intentamos y observamos muchas cosas, ninguno de los siguientes ha ayudado:

• Usando numactl para influir en las asignaciones de memoria. Notamos que g7 y g8 tienen un diseño de numa diferente, no se observó ningún efecto
• Los núcleos más nuevos (tan nuevos como 3.6) no parecían resolver esto. Tampoco lo hizo usando fedora 17.
• iostat no informa un aumento de diez veces en las transacciones de escritura, solo en el número de bytes escritos
• El uso de diferentes programadores de E / S no tiene ningún efecto.
• El montaje del sistema de archivos relevante noatime / nobarrier / nopdiratime no ayudó
• Cambiar / proc / sys / vm / dirty_ratio no tuvo efecto
• Esto sucede tanto en sistemas basados ​​en CPU 2640 como en 2670
• hpsa-3.2.0 no soluciona el problema

XFS y EL6 han caído en un estado feo ... Por el momento he abandonado XFS en los sistemas EL6 debido a varias características / cambios ascendentes que se deslizan en el núcleo de Red Hat ...

Esta fue una sorpresa y causó pánico: ¿por qué mis sistemas de archivos XFS de repente consumen más espacio y están llenos de archivos dispersos?

Desde noviembre de 2012, la versión XFS se envía en núcleos más nuevos que 2.6.32-279.11.1.el6tienen un molesto problema de carga y rendimiento derivado de Red Hat Bugzilla 860787 . Desde entonces, he tenido un rendimiento impredecible y colas de ejecución más altas que el promedio.

Para sistemas nuevos, estoy usando ZFS o simplemente ext4. Para sistemas más antiguos, los estoy congelando 2.6.32-279.11.1.el6.

Intente regresar a esa versión con:

yum install kernel-2.6.32-279.11.1.el6.x86_64

Además de lo anterior, debido al tipo de controlador RAID que está utilizando, las optimizaciones típicas están en orden:

Monta tus sistemas de archivos XFS noatime. También debe aprovechar el marco Tuned con:

tuned-adm profile enterprise-storage

para establecer una lectura básica, un nobarrier y un elevador de E / S en una buena línea base.

Editar:

Hay muchas recomendaciones sobre la optimización del sistema de archivos XFS. He usado el sistema de archivos exclusivamente durante la última década y ocasionalmente tuve que ajustar los parámetros a medida que ocurrían cambios subyacentes en el sistema operativo. No he experimentado una disminución dramática del rendimiento como la suya, pero tampoco uso LVM.

Creo que no es razonable esperar que EL5 actúe de la misma manera que EL6 , dada la diferente generación de kernel, valores predeterminados compilados, planificadores, paquetes, etc.

Lo que habría que hacer en este momento ??

• Examinaría los parámetros mkfs.xfs y cómo está construyendo los sistemas. ¿Utiliza particiones XFS durante la instalación o crea las particiones después del hecho? Realizo la creación del sistema de archivos XFS después de la instalación del sistema operativo principal porque tengo más flexibilidad en los parámetros dados.

• Mis parámetros de creación mkfs.xfs son simples: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1por ejemplo.

• Mis opciones de montaje son: noatime,logbufs=8,logbsize=256k,nobarrierpermitiría que la preasignación dinámica XFS se ejecute de forma nativa y no la limite como lo has hecho aquí. Mi rendimiento mejoró con eso.

• Entonces no uso LVM . Especialmente en la parte superior de RAID de hardware ... Especialmente en los controladores HP Smart Array, donde hay algunas funciones similares a LVM nativas del dispositivo. Sin embargo, con LVM, no tiene acceso a fdiskla creación de particiones sin formato. Una cosa que cambió de EL5 a EL6 es la alineación de la partición en el instalador y cambia a fdisk para establecer el sector de inicio en un límite de cilindro.

• Asegúrese de ejecutar sus controladores y unidades HP Smart Array en el nivel de revisión actual. En ese punto, tiene sentido actualizar todo el servidor al HP Service Pack actual para la revisión del firmware ProLiant . Este es un DVD de arranque que actualizará todos los componentes detectados en el sistema.

• Verificaría la configuración del controlador RAID. Pastebin la salida de hpacucli ctrl all show config detail. Aquí está el mío. Desea una proporción de caché sesgada hacia las escrituras frente a las lecturas. 75:25 es la norma. El tamaño de tira predeterminado de 256K debería estar bien para esta aplicación.

• Potencialmente podría intentar esto sin LVM.

• ¿Cuáles son tus sysctl.confparámetros?

Tuvimos un problema similar y descubrimos que se debe al cambio de versión del registro XFS. Los registros de la versión 2 respetan el conjunto de ancho de banda utilizado con mkfs.xfs. Si haces mucho fsync, tu tarjeta de banda ya no puede falsificar esos registros escritos. Puede probarlo formateando la partición sin ninguna configuración de ancho (no hace ninguna diferencia con RAID 1 + 0). Puede verificar eso con blktrace / seekwatcher para ver si implica mucha actualización de registro.