He notado el mismo fenómeno en mis sistemas. Las consultas que normalmente toman un milisegundo, de repente tomarán 1-2 segundos. Todos mis casos son simples declaraciones INSERT/UPDATE/REPLACE de una sola tabla --- no en ningún SELECT. No es evidente ninguna carga, bloqueo o acumulación de hilos.
Sospechaba que se debía a la limpieza de páginas sucias, al vaciado de cambios en el disco o a algún mutex oculto, pero todavía tengo que reducirlo.
También descartado
- Carga del servidor:sin correlación con una carga alta
- Motor:ocurre con InnoDB/MyISAM/Memory
- Caché de consultas de MySQL:sucede ya sea que esté activado o desactivado
- Rotaciones de registro:sin correlación en eventos
La única otra observación que tengo en este punto se deriva del hecho de que estoy ejecutando la misma base de datos en varias máquinas. Tengo una aplicación de lectura pesada, por lo que estoy usando un entorno con replicación:la mayor parte de la carga está en los esclavos. He notado que aunque hay una carga mínima en el maestro, el fenómeno ocurre más allí. Aunque no veo problemas de bloqueo, ¿tal vez Innodb/Mysql tiene problemas con la concurrencia (hilo)? Recuerde que las actualizaciones en el esclavo serán de un solo subproceso.
MySQL Versión 5.1.48
Actualizar
Creo que tengo una pista para el problema en mi caso. En algunos de mis servidores, noté este fenómeno más que en los demás. Al ver las diferencias entre los diferentes servidores y modificar las cosas, me llevaron a Variable de sistema MySQL innodb
innodb_flush_log_at_trx_commit .
Encontré el documento un poco incómodo de leer, pero innodb_flush_log_at_trx_commit puede tomar los valores de 1,2,0:
- Para 1, el búfer de registro se vacía en el archivo de registro para cada confirmación y el archivo de registro se vacía en el disco para cada confirmación.
- Para 2, el búfer de registro se vacía en el archivo de registro para cada confirmación y el archivo de registro se vacía en el disco aproximadamente cada 1 o 2 segundos.
- Para 0, el búfer de registro se vacía en el archivo de registro cada segundo y el archivo de registro se vacía en el disco cada segundo.
Efectivamente, en el orden (1,2,0), tal como se informó y documentó, se supone que debe obtener un mayor rendimiento en el comercio por un mayor riesgo.
Habiendo dicho eso, encontré que los servidores con innodb_flush_log_at_trx_commit=0 estaban funcionando peor (es decir, tenían de 10 a 100 veces más "actualizaciones largas") que los servidores con innodb_flush_log_at_trx_commit=2 . Además, las cosas mejoraron inmediatamente en las instancias malas cuando lo cambié a 2 (tenga en cuenta que puede cambiarlo sobre la marcha).
Entonces, mi pregunta es, ¿a qué está configurado el tuyo? Tenga en cuenta que no culpo a este parámetro, sino que resalto que su contexto está relacionado con este problema.
