Consulta lenta para la tabla wp_options

12

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

# 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).

    
pregunta kidakaka 06.11.2012 - 10:07

3 respuestas

13

Actualización : la razón por la que se registra la consulta es no utiliza un índice . El tiempo de consulta es 0, es decir, se ejecuta rápidamente. Puede desactivar la opción de "consultas de registro-no utilizar índices" si no desea que se registren.

La tabla wp_options no tiene índice en la carga automática, por lo que la consulta termina haciendo un escaneo 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 mayoría sí, o distribuidos uniformemente entre sí y no:

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

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

si la mayoría de ellos están configurados en "no", por ahora puede resolver el problema agregando un índice en la 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.

    
respondido por el Vinay Pai 06.11.2012 - 15:39
5

Me encontré con la consulta mencionada en mytop que se ejecuta en mi servidor hace unos días, ¡y en realidad tomó bastante tiempo (aproximadamente 10 segundos) para cada consulta! Así que hay situaciones del mundo real donde wp_options podría crecer hasta un tamaño problemático. En mi caso, sospecho que el complemento de almacenamiento en caché Cachify es responsable de la hinchazón de las opciones wp.

Datos de este particular wp_options:

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.

    
respondido por el Jan Papenbrock 27.03.2013 - 19:19
0

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

Resulta que se han insertado alrededor de 150 opciones transitorias en la tabla, pero no se han 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 varios servidores de Servicios Web de Amazon (presumiblemente comprometidos) (a partir de las direcciones IP con 54.XXX y 32.XXX) había estado intentando explotar /~web-root-dir/xmlrpc.php.

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

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

Uno de los campos devueltos de esta consulta es 'option_value' que tiene un tipo de datos de 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 trabajaban 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 de wp-cron con la esperanza de que fueran ejecutados durante el ciclo (s) de cron.

Mi solución fue eliminar todas las filas "transitorias". Esto no perjudicará 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:

ELIMINAR de wp_options donde option_name es como '% transient %';

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

    
respondido por el Ex_Military 07.09.2017 - 03:55

Lea otras preguntas en las etiquetas