1. Entorno del sistema
SO: CentOS Linux versión 7.8.2003 (Core)
Kernel: 3.10.0-1127.19.1.el7.x86_64
MySQL: Tanto la 5.0 como la 5.7 tienen este problema, no debería tener nada que ver con la versión
2. Herramientas de medición de presión
benchyou [1]
mysql_random_load [2]
3. Fenómeno problemático
Cuando se usa la herramienta mysql_random_load para conectarse a MySQL para escribir datos, el rendimiento es muy bajo.
Dado que la herramienta mysql_random_load no admite la conexión de socket, tuve que rendirme y usar benchyou en su lugar . Por cierto, benchyou y sysbench son muy similares, pero también muy fáciles de usar.
Después de cambiar a la herramienta de banco , la prueba de presión es normal. No parece ser un problema con la versión de MySQL.
Cuando se usa la herramienta mysql_random_load para realizar pruebas de estrés, la carga del sistema es muy alta y se puede observar que la interrupción del sistema también es alta y desigual.
[[email protected]]# vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 73585 2 41051 0 0 117 91 4 2 0 0 99 0 0
2 0 0 73585 2 41051 0 0 0 28320 55444 100207 18 2 80 0 0
4 0 0 73584 2 41052 0 0 0 1936 52949 98607 18 2 81 0 0
2 0 0 73583 2 41052 0 0 0 4864 56375 101262 14 2 84 0 0
4 0 0 73583 2 41052 0 0 0 29064 55806 103715 19 2 80 0 0
5 0 0 73583 2 41052 0 0 0 5704 55854 98386 15 2 83 0 0
Se puede ver que el valor de la columna system.in es muy alto Después de cambiar a la herramienta benchyou , el valor de esta columna ha bajado de 55,000 a 16,000.
[[email protected]]# vmstat -S m 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 0 77238 2 38371 0 0 118 88 2 3 0 0 99 0 0
2 0 0 77234 2 38374 0 0 0 31620 16039 77988 3 2 95 0 0
2 0 0 77231 2 38377 0 0 0 31996 16091 78926 3 2 95 0 0
3 0 0 77229 2 38378 0 0 0 33028 16347 81006 3 2 95 0 0
0 0 0 77226 2 38383 0 0 0 52412 15496 75715 3 2 95 0 0
2 0 0 77224 2 38384 0 0 0 32252 16167 79352 3 2 95 0 0
Veamos el rendimiento de la interrupción del sistema cuando hay un problema.
[[email protected]]# mpstat -I SUM -P ALL 1
Linux 3.10.0-1127.19.1.el7.x86_64 (yejr.run) 09/28/2020 _x86_64_ (32 CPU)
05:37:40 PM CPU intr/s
05:37:41 PM all 51833.00
05:37:41 PM 0 2069.00
05:37:41 PM 1 1159.00
05:37:41 PM 2 2979.00
05:37:41 PM 3 1580.00
05:37:41 PM 4 1627.00
05:37:41 PM 5 1461.00
05:37:41 PM 6 1243.00
05:37:41 PM 7 1825.00
05:37:41 PM 8 2154.00
05:37:41 PM 9 1367.00
05:37:41 PM 10 1277.00
05:37:41 PM 11 1376.00
05:37:41 PM 12 4085.00
05:37:41 PM 13 1601.00
05:37:41 PM 14 4045.00
05:37:41 PM 15 1857.00
05:37:41 PM 16 1692.00
05:37:41 PM 17 722.00
05:37:41 PM 18 118.00
05:37:41 PM 19 1862.00
05:37:41 PM 20 1637.00
05:37:41 PM 21 1130.00
05:37:41 PM 22 1750.00
05:37:41 PM 23 1653.00
05:37:41 PM 24 1417.00
05:37:41 PM 25 1547.00
05:37:41 PM 26 1500.00
05:37:41 PM 27 1033.00
05:37:41 PM 28 20.00
05:37:41 PM 29 1683.00
05:37:41 PM 30 888.00
05:37:41 PM 31 1549.00
Puede verse que el número total de interrupciones por segundo es 55.000, pero las múltiples CPU no están equilibradas.
4. Análisis de problemas
Inicialmente se determinó que el rendimiento de escritura era deficiente debido a las altas interrupciones del sistema y también se determinó que este problema se debía al desequilibrio de las interrupciones entre varias CPU.
Observe qué interrupciones son relativamente altas y descubra que LOC y RES tienen un aumento relativamente grande por segundo.
[[email protected]]# watch -d cat /proc/interrupts
...
LOC: 2468939840 2374791518 2373834803 2373613050 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
IWI: 50073298 45861632 45568755 45833911 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 3472920231 3022439316 2990464825 3012790828 Rescheduling interrupts
CAL: 5131479 6539715 17285454 11211131 Function call interrupts
TLB: 23094853 24045725 24230472 24271286 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
...
Después de intentar modificar la CPU vinculada al número de interrupción relevante (consulte: afinidad SMP y manejo adecuado de interrupciones en Linux [3]), el problema aún no se ha solucionado.
Más tarde, un jefe misterioso dio algunos consejos y descubrió que se trataba de un error del kernel, que involucraba el parámetro kernel.timer_migration , que debe establecerse en 0.
[[email protected]]# sysctl -w kernel.timer_migration=0
Por supuesto, es mejor escribirlo de forma persistente en el archivo /etc/sysctl.conf .
[[email protected]]# cat /etc/sysctl.conf
kernel.timer_migration=0
#加载配置文件使之生效
[[email protected]]# sysctl -p
Use la herramienta mysql_random_load para realizar una prueba de esfuerzo nuevamente y estará bien.
La siguiente es una descripción del error.
The bug is when linux os receive too many tcp packages,
and the tcp may add too many timer, but in
get_target_base->get_nohz_timer_target it check current
cpu is idle, sometimes thouth the current core is very busy,
but the idle_cpu result is 1, in this time
if set kernel.timer_migration=1 ,the timer will be move to next cpu.
error 详情见 ：Error 124661 - kernel.timer_migration = 1 causa demasiadas interrupciones de reprogramación [4]
Finalmente, vale la pena mencionar que la modificación de este parámetro en el host en la nube no debería funcionar a menos que se modifique la máquina física. Me encontré con un problema similar al ejecutar la prueba de presión de la herramienta mysql_random_load en un host en la nube. El problema persistió después de modificar los parámetros del kernel.
Enlace en texto
[1]: https: //github.com/xelabs/benchyou
[2]: https: //github.com/Percona-Lab/mysql_random_data_load
[3]: http: //www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux
[4]: https: //bugzilla.kernel.org/show_bug.cgi? Id = 124661
El texto completo ha terminado.
Disfrute de Linux y MySQL :)
El curso "MySQL Core Optimization" se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la capacitación de MySQL.