web-dev-qa-db-fra.com

Requête lente pour la table wp_options

J'ai suivi le journal des requêtes lentes du site basé sur WP (avec la valeur par défaut de a long_query_time défini sur 10) et j'ai remarqué que la requête suivante était souvent journalisée -

# 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';

Je ne comprends pas comment une si petite table peut prendre autant de temps à s'exécuter. Est-ce juste un symptôme d'un autre problème? (Exécution de Moodle, phpbb et WP sur une machine virtuelle dédiée).

performancewp-options
15
Prasad Ajinkya

Update : La raison pour laquelle la requête est enregistrée est/ n'utilise pas d'index . Le temps de la requête est 0, c’est-à-dire qu’il s’exécute rapidement. Vous pouvez désactiver l'option "Journaliser les requêtes sans utiliser d'index" si vous ne souhaitez pas qu'elles soient consignées.

La table wp_options n'a pas d'index sur le chargement automatique, donc la requête finit par effectuer une analyse complète de la table. En général, ce tableau ne devrait pas devenir trop volumineux, donc ce n'est pas un problème, mais je suppose que c'est ce qui s'est passé dans votre cas.

Ajouter un index peut résoudre le problème, mais comme TheDeadMedic l'a souligné dans les commentaires, il se peut que cela ne soit pas le cas si les valeurs de l'autoload sont soit majoritaires, soit égales entre yes et no:

Commencez par cette requête pour voir à quoi ressemble la distribution:

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

si une grande majorité d'entre elles sont définies sur "non", vous pouvez résoudre le problème pour l'instant en ajoutant un index sur le chargement automatique.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Cependant, vous voudrez peut-être comprendre pourquoi ce tableau est devenu trop volumineux. Peut-être un plugin mal écrit faisant quelque chose de louche.

16
Vinay Pai

Je suis tombé par hasard sur la requête mentionnée dans mytop en cours d'exécution sur mon serveur il y a quelques jours - et cela a effectivement pris un certain temps (environ 10 secondes) pour chaque requête! Il existe donc des situations réelles où wp_options peut atteindre une taille problématique. Dans mon cas, je soupçonne que le plugin de mise en cache Cachify est responsable des ballonnements wp_options.

Données de ce wp_options:

5,309 rows
130MB of data

En guise de solution, j'ai ajouté un index similaire à celui de Vinay Pai, qui a résolu le problème sans faille.

5
Jan Papenbrock

Ma table wp_options ne contient qu'environ 235 lignes de données. J'ai essayé d'indexer la table, mais cela n'a pas aidé.

Il s'avère qu'environ 150 options transitoires ont été insérées dans la table, mais n'ont pas été automatiquement supprimées.

Je ne sais pas si c'est lié ou non, mais j'avais parcouru mes fichiers /var/log/Apache2/access.log et avais remarqué que plusieurs serveurs (probablement compromis) Amazon Web Services (adresses IP commençant par 54. XXX et 32.XXX) avaient tenté d’exploiter /~web-root-dir/xmlrpc.php.

Après un dépannage, j'ai interrogé la table wp_options pour des noms d'options contenant "transitoire".

sélectionnez * dans wp_options où nom_option sera tel que '% transitoire %';

L'un des champs renvoyés par cette requête est 'option_value', qui a le type de données LONGTEXT. Selon les documents mySQL, un champ LONGTEXT (pour chaque ligne) peut contenir jusqu'à 4 gigaoctets de données.

Lorsque j'ai exécuté la requête, certaines des lignes (rappelez-vous, travaillaient avec celles contenant "transitoire") contenaient massive quantités de données dans le champ option_value. En regardant à travers les résultats, j'ai également vu ce qui ressemblait à des tentatives d'injection de commandes dans le processus wp-cron avec l'espoir qu'elles seraient exécutées pendant le (s) cycle (s) cron.

Ma solution a été de supprimer toutes les lignes "transitoires". Cela ne fera pas mal au serveur car les lignes "transitoires" se repeupleront automatiquement (si elles sont supposées être là).

Après cela, le serveur était à nouveau réactif.

Requête pour supprimer ces lignes:

DELETE de wp_options où nom_option est semblable à '% transitoire %';

J'ai également ajouté l'adresse IP AWS/8 superblocs à mon pare-feu (-:

1
Ex_Military