☰

Buscando comparaciones de E/S de disco para un servidor MySQL dedicado

tag-icon • tag-icon mysql performance performance-tuning
Buscando comparaciones de E/S de disco para un servidor MySQL dedicado

Contratamos a un consultor para que nos ayudara a aumentar la capacidad de nuestro clúster MySQL, y lo primero (casi lo único) que hizo fue medir la velocidad de E/S del disco de nuestros servidores.

Estoy interesado en una comparación de E/S de disco en sistemas similares al que tenemos:

  • Nuestros servidores MySQL son servidores virtuales que se ejecutan en VMWare ESX 3.5 de 32 bits con SCSI SAN (Raid 5), y los servidores virtuales en sí ejecutan Debian Etch y MySQL versión 5.0.32.

Ejecutar los siguientes comandos en el cuadro de MySQL me da estos resultados (que el consultor describió como "terriblemente lento":

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 71.3347 seconds, 14.7 MB/s
real    1m13.596s
user    0m0.052s
sys 0m56.932s

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 21.8202 seconds, 48.1 MB/s
real    0m21.902s
user    0m0.012s  
sys 0m7.948s

¿Son realmente estos resultados "terriblemente lentos"?

Me interesaría comparar los resultados que otras personas obtienen con estos 2 comandos en sus cajas MySQL dedicadas, especialmente si se trata de una máquina virtual de 32 bits.

Respuesta1

Algo a tener en cuenta es que su comando dd no pasará por alto el caché del sistema de archivos del sistema operativo. Esto significa que obtendrá resultados variables dependiendo de lo que esté sucediendo y notará una variación significativa en el rendimiento a medida que aumente el tamaño de salida (y, por lo tanto, agote su caché fs).

Agregue "oflag=direct" para omitir el caché del sistema de archivos en el archivo de salida, por ejemplo

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct

Puede omitir el caché del sistema de archivos para lectura usando iflag=direct

Además, su rendimiento variará mucho según el tamaño del bloque. Si bien 1M es una compensación bastante buena para probar escrituras secuenciales, a menos que su aplicación escriba bloques de 1M, no será representativa de su rendimiento real.

Como punto general, esas cifras de rendimiento son bastante abismales: una sola unidad sata (como las unidades Seagate ES.2) puede alcanzar un máximo de 105 MB/s de escritura secuencial al inicio de la unidad y mantendrá ~60 MB/s a lo largo del tiempo. todo el recorrido.

Finalmente, las "mejores prácticas" generales de bases de datos dicen que se debe evitar RAID5/6 como sistema subyacente para una base de datos, debido a la sobrecarga relativamente alta causada por las escrituras de paridad (no el cálculo de paridad real en sí, que es bastante barato en hardware, sino el efecto de tener que realizar lecturas y escrituras adicionales al escribir una nueva paridad).

Respuesta2

Aquí están los resultados de mi servidor MySQL. Es una máquina de 64 bits, no virtual, por lo que no estoy seguro de cuánto uso realmente tiene, pero hay una diferencia muy considerable.

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s
0.00s user 1.55s system 27% cpu 5.725 total

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s
0.00s user 0.45s system 103% cpu 0.436 total

Respuesta3

en la mayoría de los casos también deberías comparar io aleatorio [por ejemplo, conbonnie++] no solo lectura/escritura lineal. ¿O tal vez es un gran sumidero de datos que toma registros y los almacena en una tabla enorme no indexada?

resultados para dd 'punto de referencia'

szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s

real    0m4.563s
user    0m0.001s
sys     0m2.255s
szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s

real    0m0.459s
user    0m0.000s
sys     0m0.459s
szcapp1:/mnt/big/tmp#

Linux de 64 bits en Dell Poweredge 2950, ​​Perc6 Raid 10 en 5 discos sata de escritorio de 500 GB. 16 GB de RAM, 2x cuatro núcleos a 2,66 GHz. ¡pero hey! Esto no tiene sentido: estos datos caben en 1/4 de la memoria caché del controlador raid y el resto, en la memoria del sistema.

tus resultados son realmente lentos. resultados de la máquina virtual que se ejecuta en Linux anterior [invitado Linux de 32 bits en el servidor vmware 2.0]:

vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s

real    0m16.043s
user    0m0.016s
sys     0m13.117s
vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s

real    0m0.505s
user    0m0.000s
sys     0m0.500s
vfeed0:/tmp#

tenga en cuenta que el rendimiento de lectura es falso: se lee desde el caché; si no desde el caché del invitado, entonces desde el caché del host vmware.

Respuesta4

Algo alejado de tu pregunta original; pero la respuesta del proveedor de SAN a "RAID 5 es lento" es convertir a RAID 1 o RAID 10. Considere también la alineación de VMFS (PDF) puede estar afectando gravemente al rendimiento.

información relacionada