Hemos experimentado una disminución masiva ocasional en el rendimiento de ACTUALIZACIÓN en nuestra base de datos.MySQL/InnoDB de vez en cuando algunas actualizaciones se ejecutan muy lentamente, en el estado 'Actualización'
Por ejemplo, en la tabla FooTable tenemos cerca de 40 columnas con un PK varchar, además hay 10 índices. La siguiente consulta tomó 44 segundos, mientras que en otras ocasiones se ejecutó de manera prácticamente instantánea. Durante la ralentización, el promedio de carga en el servidor es bastante bajo (1.5 para el promedio de 5 minutos) y IO según vmstat es bastante razonable también.
Aquí un ejemplo:
mysql> update FooTable set BarColumn=1349981286086 where varcharPK='e4348411-0fbb-460a-80f7-f1de304a9f7c'
Query OK, 1 row affected (44.94 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> show profile for QUERY 1;
+----------------------+-----------+
| Status | Duration |
+----------------------+-----------+
| starting | 0.000030 |
| checking permissions | 0.000004 |
| Opening tables | 0.000007 |
| System lock | 0.000003 |
| Table lock | 0.000003 |
| init | 0.000035 |
| Updating | 44.949727 |
| end | 0.000006 |
| query end | 0.000003 |
| freeing items | 0.000115 |
| logging slow query | 0.000002 |
| logging slow query | 0.000052 |
| cleaning up | 0.000003 |
+----------------------+-----------+
13 rows in set (0.02 sec)
Por lo que vale la consulta ejemplo anterior se ejecuta en una tabla InnoDB que fue 'reconstruido' (ALTER TABLE FooTable ENGINE = InnoDB;) menos de una semana atrás. Inicialmente sospeché que esto estaba relacionado con los problemas de rendimiento conocidos de InnoDB con PKs varchar/no secuenciales, sin embargo, tenemos otras tablas que usan PK secuencial y han visto los mismos problemas.
Esto está en un servidor de producción: Centos 5 2.6.18-238.19.1.el5 x86_64 MySQL/Percona 05/01/57-rel12.8-log 96 GB de memoria con 58.8G de datos extendido por 87 tablas
la configuración InnoDB relevent son los siguientes:
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 70G
innodb_log_file_size = 512M
innodb_log_buffer_size = 64M
innodb_file_per_table = 1
innodb_thread_concurrency = 0
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
optimizer_search_depth = 0
innodb_file_format = barracuda
no estoy usando FORMATO = comprimen en esta tabla, sin embargo estoy en los demás.
¿Alguna sugerencia sobre cómo descubrir lo que está pasando en la fase de actualización que lleva tanto tiempo?
¿'EXPLAIN' funciona con' UPDATE'? ¿Obtiene el mismo rendimiento con un 'SELECT BarColumn FROM FooTable WHERE varCharPK = ...'? Me pregunto si está haciendo algo raro con los índices. –
No se puede ejecutar una explicación en una ACTUALIZACIÓN, sin embargo, si la convierto en SELECCIONAR, se ve como debería, está usando la clave PRIMARIO, filas 1. – Jeremy
Intente hacer una "LISTA DE PROCESOS" mientras se está ejecutando esa consulta. Puede mostrar otras consultas que tienen un bloqueo en la tabla. – bobwienholt