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
mkfs.xfsymountopciones. EL6 es consciente de la alineación de partición. HPSA estaría en uso para ambos tipos de controladores Smart Array bajo EL6, pero EL5 usaría CCISS.Respuestas:
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:
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: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?fuente
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.
fuente
mkfs.xfscadena de comando?