¿Por qué los hilos de MySQL a menudo muestran el estado de "liberación de elementos" cuando la caché de consultas está desactivada?

16

Cuando ejecuto SHOW PROCESSLIST, a menudo hay una gran cantidad de subprocesos INSERT / UPDATE en el estado "liberando elementos".

El manual de MySQL sugiere que al menos parte de la razón por la que un subproceso está en este estado involucra la caché de consultas, presumiblemente sería invalidar las consultas en caché debido a los datos modificados.

Sin embargo, mi query_cache_sizeestá establecido en 0, lo que debería deshabilitar la caché de consultas por completo.

¿Qué otras razones habría para tener tantos hilos en este estado?

Las tablas relevantes usan el motor de almacenamiento InnoDB.

mysql innodb

— Dan Grossman
fuente

7

Verifique el valor de innodb_thread_concurrency.

Para mi sistema, aumentar el valor de 8 a 32, según las pautas en la documentación de MySql , causó una disminución perceptible en el número de subprocesos que informan simultáneamente el estado de "liberación de elementos". Además, el tiempo promedio de consulta obesrved disminuyó en un orden de magnitud.

Si bien esto marcó una gran diferencia en el rendimiento general del servidor, no fue la bala de plata de "liberar elementos". Mi ecosistema de hardware me lleva a plantear la hipótesis de que este estado se ve principalmente en sistemas con discos "lentos" (2x10k discos raid 1), y es menos frecuente en sistemas con almacenamiento más rápido (12x15k discos raid 10). Por lo tanto, una comprobación del rendimiento del disco también puede estar justificada.

¡Buena suerte!

También:

Vale la pena señalar que el valor predeterminado de innodb_thread_concurrency es radicalmente diferente dependiendo de qué versión de 5.0 puntos se esté utilizando.

El valor predeterminado ha cambiado varias veces: 8 antes de MySQL 5.0.8, 20 (infinito) de 5.0.8 a 5.0.18, 0 (infinito) de 5.0.19 a 5.0.20 y 8 (finito) de 5.0.21 en. - fuente

Esto significa que una actualización aparentemente inocua de 5.0.20 a 5.0.21 cambió el valor predeterminado de infinito a 8 y trajo consigo las ramificaciones de rendimiento.

— jphofmann
fuente

Tenía un problema similar como este, y estaba directamente relacionado con las velocidades lentas del disco duro. El análisis de la velocidad del disco mostró que escribir y leer en el disco duro era extremadamente lento. Esto tuvo un efecto negativo en MySQL, y es por eso que los estados de "Liberación de elementos" (con las mismas consultas) se mostraban durante mucho tiempo en la lista de procesos. Matar los otros procesos que estaban disminuyendo la velocidad del disco duro solucionó el problema.

— Navigatron

5

La liberación de elementos es una etapa de ejecución de consultas donde se desasignan estructuras temporales, buffers, etc. En esta etapa se realiza algo de trabajo de caché de consultas, pero eso no es lo único que sucede allí. Sugeriría usar SHOW PROFILES para ver cuánto tiempo lleva esta etapa en relación con otras etapas, y si el tiempo consumido termina siendo una preocupación, solucione problemas con herramientas como el perfilador y el perfil profesional del pobre.

— Baron Schwartz
fuente

Gracias por centrarse en lo que es "liberar elementos". ¿Hay algún documento específico que lo detalle, o es solo un ejercicio de Google para mí?

— RolandoMySQLDBA

¡O explore el ejercicio del código fuente! :)

— Derek Downey

3

Hubo un informe de error sobre este problema relacionado con la "liberación de elementos" y la caché de consultas . Aunque el error está cerrado, no se mencionó innodb_thread_concurrency .

Con coincidencia, hablé con Ronald Bradford en Percona Live NYC en mayo. Le conté una situación en la que modifiqué innodb_thread_concurrency porque el InnoDB Buffer Pool múltiple de MySQL 5.5 produjo toneladas de bloqueo de subprocesos y sospeché que los datos en caché que necesito probablemente se hayan extendido entre los múltiples pools de buffer.

Claramente me dijo que nunca debería establecer valores contra innodb_thread_concurrency. Deje que siempre sea el valor predeterminado, que ahora es cero (0). Al hacerlo, deja que el almacenamiento de InnoDB decida cuántos innodb_concurrency_tickets generar por sí mismo. Esto es lo que hace la concurrencia infinita.

Lo más probable es que 'liberar elementos' ocurra más a menudo cuando imponemos límites a innodb_thread_concurrency. Eso siempre debe ser cero (0). Me arriesgaría y subiría innodb_concurrency_tickets y vería si ayuda o no.

— RolandoMySQLDBA
fuente

2

Tuvimos un problema con exactamente los mismos síntomas. Resultó que el disco con los archivos de registro de InnoDB se ha llenado. Vale la pena revisarlo.

— RedBlueThing
fuente

Necesita archivos de registro mucho más grandes. De hecho, los archivos de registro más grandes permitidos con innodb_log_files_in_group default (que es 2) son 2047M. Debe cerrar mysql, rm -f / var / lib / ib_logfile [01], hacer innodb_log_file_size = 2047M en /etc/my.cnf e iniciar mysql. ¡Por supuesto, consigue un disco más grande!

— RolandoMySQLDBA

1

Otra pista: podría ser innodb fsync (). Intenta configurar

innodb_flush_log_at_trx_commit = 2

En my.cnf

El archivo de registro innodb se vacía en el disco cada 1-2 segundos, en lugar de ob en cada confirmación. Ligera penalización para la integridad de los datos, gran ganancia de velocidad.

— Sto
fuente