Consulta lenta para la tabla wp_options


16

He estado rastreando el registro de consultas lentas del sitio basado en WP (con el valor predeterminado de long_query_time establecido en 10), y he notado que la siguiente consulta a menudo se registra:

# User@Host: root[root] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 394  Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

No entiendo cómo una tabla tan pequeña puede tardar tanto tiempo en ejecutarse. ¿Es esto solo un síntoma de algún otro problema? (Actualmente ejecuta Moodle, phpbb y WP en una máquina virtual dedicada).

Respuestas:


16

Actualización : la razón por la que se registra la consulta es porque no utiliza un índice . El tiempo de consulta es 0, es decir, se ejecuta rápidamente. Puede deshabilitar la opción "log-queries-not-using-indexes" si no desea que se registren.

La tabla wp_options no tiene índice de carga automática, por lo que la consulta termina haciendo un análisis completo de la tabla. En general, esa tabla no debería ser demasiado grande, por lo que no es un problema, pero supongo que de alguna manera sucedió en su caso.

Agregar un índice podría resolver el problema, pero como TheDeadMedic señaló en los comentarios, podría no ser así si los valores de carga automática son sí mayoritarios o están distribuidos de manera uniforme entre sí y no:

Primero, haga esta consulta para ver cómo se ve la distribución:

SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;

Si una gran mayoría de ellos están configurados como 'no', puede resolver el problema por el momento agregando un índice de carga automática.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Sin embargo, es posible que desee llegar al fondo de por qué esa tabla se ha vuelto demasiado grande. Posiblemente algún plugin mal escrito haciendo algo sospechoso.


2
Dudo que un índice en este caso ofrezca alguna ganancia: consulte este artículo sobre cardinalidad .
TheDeadMedic

Depende de si la mayoría de las opciones están configuradas para autocarga o no. Creo que no, pero en la mesa nunca debería ser tan grande de todos modos, así que algo sospechoso está sucediendo.
Vinay Pai

1
Actualicé por respuesta para agregar un poco sobre la comprobación de la distribución de valores.
Vinay Pai

1
Acabo de notar el comentario y me di cuenta de que mi respuesta es completamente incorrecta. La consulta no es realmente lenta ... solo se registra en el registro de consulta lenta porque no usa un índice.
Vinay Pai

1
Gracias a esta pregunta y respuesta, descubrí que tenía 90k entradas en mi tabla wp_options, 88.5k de las cuales estaban configuradas para cargar automáticamente false. El resto eran todas entradas "transitorias" agregadas por complementos (¿presumiblemente para almacenamiento en caché?). Agregar un índice a la columna de carga automática redujo mi carga mySql de un promedio de 89% a 2.5% al ​​instante. Los agentes de monitoreo muestran que el tiempo de respuesta de mi sitio se ha reducido de 1900ms a 500ms. Esto fue un cambio de juego para mí.
Mordred

5

Me topé con la consulta mencionada en mytop ejecutándose en mi servidor hace unos días, ¡y en realidad me llevó bastante tiempo (unos 10 segundos) para cada consulta! Por lo tanto, hay situaciones del mundo real en las que wp_options podría crecer hasta un tamaño problemático. En mi caso, sospecho que el plugin de almacenamiento en caché Cachify es responsable de hinchar wp_options.

Datos de este wp_options particular:

5,309 rows
130MB of data

Como solución, agregué el índice similar a la solución publicada por Vinay Pai, que resolvió el problema sin problemas.


1

Mi tabla wp_options solo tenía aproximadamente 235 filas de datos. Intenté indexar la tabla, pero no sirvió de nada.

Resulta que alrededor de 150 opciones transitorias se habían insertado en la tabla, pero no se habían eliminado automáticamente.

No sé si está relacionado o no, pero había estado revisando mis archivos /var/log/apache2/access.log y noté que múltiples servidores de servicios web de Amazon (presumiblemente comprometidos) (direcciones IP que comienzan con 54. XXX y 32.XXX) habían estado intentando explotar /~web-root-dir/xmlrpc.php.

Después de resolver algunos problemas, pregunté en la tabla wp_options los nombres de las opciones que contenían "transitorios"

seleccione * de wp_options donde option_name como '% transient %';

Uno de los campos devueltos por esta consulta es 'option_value' que tiene un tipo de datos LONGTEXT. Según los documentos de mySQL, un campo LONGTEXT (para cada fila) puede contener hasta 4 Gigabytes de datos.

Cuando ejecuté la consulta, algunas de las filas (recuerde que estaban trabajando con las que contenían "transitorias") tenían cantidades masivas de datos en el campo option_value. Mirando los resultados, también vi lo que parecían intentos de inyectar comandos en el proceso wp-cron con la esperanza de que se ejecuten durante el (los) ciclo (s) cron.

Mi solución fue eliminar todas las filas "transitorias". Esto no dañará al servidor ya que las filas "transitorias" se repoblarán automáticamente (si se supone que deben estar allí).

Después de hacer esto, el servidor volvió a responder.

Consulta para eliminar estas filas:

DELETE de wp_options donde option_name como '% transient %';

También agregué la dirección IP de AWS / 8 superbloques a mi firewall (-:


Sí. También estaba sufriendo un "tiempo de carga de 40 segundos" hasta que descubrí que tenía 20,000 registros wp_option con datos masivos que se cargaban en cada página. Eliminarlos aceleró considerablemente el sitio.
JasonGenX
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.