MySQL table_cache y Opened_tables

He visto a personas usar la comparación de Open_tables y Opened_tables para evaluar si table_cache es demasiado pequeño en MySQL. Sin embargo, creo que Opened_tables es acumulativo durante el tiempo de actividad, por lo que esta no es una comparación válida. La única advertencia es que quizás Opened_tables solo se topa con errores, aunque incluso si las tablas que se abren por segundo todavía son pequeñas, probablemente no sea un problema para que crezca gradualmente.

Si comparar Open_tables con Opened_tables no es válido, ¿hay otra forma de obtener datos medidos para esto?

Esto está en MySQL 5.0, pero las diferencias entre versiones también son bienvenidas.

La razón más importante para tener una tabla_caché grande es que el mutex LOCK_open no está activo . MySQL anterior a 5.5 tiene mucha controversia cuando intenta abrir / cerrar tablas, por lo que desea restringir esto tanto como sea posible, es decir, tener un caché de tabla grande.

Por lo tanto, no le importa ninguna proporción particular de aciertos y errores (de hecho, debe ignorar las proporciones por completo; esta publicación de blog explica por qué ). Lo que le importa es la tasa de fallas , porque cuantas más veces ocurra esto por segundo, mayor será la probabilidad de que tenga una disputa (un hilo tiene que esperar a que otro hilo libere el bloqueo).

¿Cómo detectas la tasa de fallas? Obtiene algunas muestras de Opened_Tables con unos segundos de diferencia durante el período más ocupado del día, y si hay aumentos en cada muestra, probablemente sea una buena idea ver si puede aumentar el table_cache.

Nota: Muy específicamente no recomiendo comparar con el tiempo de actividad.

Primero, consideremos esas variables de estado:

Tablas abiertas : el número de tablas que están abiertas.

Tablas_Abiertas : El número de tablas que se han abierto. Si Opened_tables es grande, su valor table_open_cache es probablemente demasiado pequeño.

Sorprendentemente, la respuesta a su pregunta se encuentra dentro de la pregunta misma.

Las dos variables solo tendrían más sentido si agrega una variable de estado más a la mezcla: Uptime (o Uptime_since_flush status para promedios nuevos después de FLUSH STATUS ).

Debería comparar Open_tables agsinst (Opened_tables / Uptime) . Si Open_tables sube por encima (Opened_tables / Uptime) , ahora tiene motivos para preocuparse y debe estar atento a cosas como las siguientes:

• netstat
• iostat
• carga del servidor
• Recuento de conexiones (a medida que se acerca a max_ connections )
• Clientes abortados
• Conexiones abortadas
• Consultas lentas

ACTUALIZACIÓN 2011-08-31 12:18 EDT

Tenga en cuenta por qué también sugerí usar Uptime_since_flush_status en lugar de Uptime para obtener un patrón fijo de crecimiento Opened_tables para un período determinado.

Por ejemplo, si ejecuta FLUSH STATUS;todos los lunes a la medianoche, puede generar un OpenTableFactor:

SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM
(SELECT variable_value Uptime FROM information_schema.global_status
WHERE variable_name = 'Uptime_since_flush_status') up,
(SELECT variable_value Open_tables FROM information_schema.global_status
WHERE variable_name = 'Open_tables') opn,
(SELECT IF(variable_value=0,1,variable_value) Opened_tables
FROM information_schema.global_status
WHERE variable_name = 'Opened_tables') opnd;

Este factor de tabla abierta equivale al número que representa el número de tablas abiertas en un momento dado contra el número promedio de tablas abiertas durante un período determinado. Con FLUSH HOSTS;cada semana / día / host, ese promedio está en contra de la semana / día / hora.

Aquí hay una muestra de uno de los clientes de mi empleador:

mysql> SELECT *, (Open_tables * Uptime / Opened_Tables) OpenTableFactor FROM     (SELECT variable_value Uptime FROM information_sc    hema.global_status     WHERE variable_name = 'Uptime_since_flush_status') up,     (SELECT variable_value Open_tables FROM informat    ion_schema.global_status     WHERE variable_name = 'Open_tables') opn,     (SELECT IF(variable_value=0,1,variable_value) Opened_ta    bles     FROM information_schema.global_status     WHERE variable_name = 'Opened_tables') opnd;
+----------+-------------+---------------+-------------------+
| Uptime   | Open_tables | Opened_tables | OpenTableFactor   |
+----------+-------------+---------------+-------------------+
| 14385123 | 16326       | 30429078      | 7717.996519579068 |
+----------+-------------+---------------+-------------------+
1 row in set (0.00 sec)

Este cliente normalmente mantiene alrededor de 7745 OpenTableFactor al máximo. Si OpenTableFactor cae repentinamente (aunque sea un poco), podría indicar patrones de tráfico más bajos, conexiones abortadas altas, etc. Si OpenTableFactor nunca cambia (aunque sea un poco), podría presentarte la oportunidad de cambiar esta configuración:

• open_files_limit
• innodb_open_files
• table_open_cache

Una vez ajustado, OpenTableFactor puede cambiar constantemente o alcanzar otro techo o meseta. Por lo tanto, el uso de diferentes unidades dentro de las variables de estado se vuelve vital para este tipo de ajuste.

ACTUALIZACIÓN 2011-08-31 12:42 EDT

La consulta SQL que ejecuté para OpenTableFactor no funciona para MySQL 5.0 y viceversa. Si está utilizando MySQL Administrator o MONyog , puede personalizar un gráfico utilizando la fórmula en la consulta y el monitor. MONyog recopila el historial utilizando SQLLite para gráficos históricos posteriores. Esto se puede hacer para cualquier versión de MySQL.

De uno de los comentarios de los usuarios en la página de documentación de table_cache :

Opened_tables es una variable de estado que mantiene una cuenta corriente del número de descriptores de archivo adicionales que se han asignado para abrir tablas en momentos en que los descriptores de archivo disponibles en table_cache se han agotado. ...

Lo que significa que se incrementa cuando superas tu table_cachevalor. Por lo que la forma en que normalmente comprobar esto es para comparar opened_tablescon uptime, pero la clave aquí es tomar lo largo de un intervalo de tiempo establecido (una vez por minuto más de diez minutos, por ejemplo). Si está aumentando, puede ser una indicación de que necesita aumentar su table_cache.

Un par de advertencias para mencionar:

• Otro comentario en la documentación anterior: "La variable de estado 'Opened_tables' también se incrementará en 2 cada vez que cree una tabla temporal". Entonces, si sus consultas requieren muchas tablas temporales, esto podría ser la causa de un rápido aumento en opened_tables. Puede ver el uso de su tabla temporal utilizando la siguiente consulta:

  SHOW GLOBAL STATUS LIKE '%tmp%';

• No aumente la table_cache demasiado alta

  La razón de tal comportamiento es que, si tiene un no grande. de tablas con consultas complicadas que se unen a varias tablas y conexiones múltiples que ejecutan esas consultas complicadas, puede terminar usando el caché de todos los descriptores de archivos (table_cache) en ese caso MySQL usa un algoritmo para encontrar el descriptor utilizado menos recientemente, lo cierra y lo reemplaza con un nuevo descriptor.