requête lente pour la table wp_options

12

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

# [email protected]: 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écutant actuellement Moodle, phpbb et WP sur une machine virtuelle dédiée).

    
posée kidakaka 06.11.2012 - 10:07

3 réponses

13

Mettre à jour : la raison pour laquelle la requête est consigné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. Ce n’est donc pas un problème, mais j’imagine que c’est arrivé 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 autoload sont soit majoritaires, soit égales entre yes et no:

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

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

si une grande majorité d'entre eux sont réglés 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 aller au fond des raisons pour lesquelles ce tableau est devenu trop volumineux. Peut-être un plugin mal écrit faisant quelque chose de louche.

    
réponse donnée Vinay Pai 06.11.2012 - 15:39
5

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 plug-in de mise en cache Cachify soit responsable du gonflement des wp_options.

Données de ce wp_options particulier:

5,309 rows
130MB of data

Comme solution, j’ai ajouté l’indice similaire à celui de Vinay Pai, qui résout parfaitement le problème.

    
réponse donnée Jan Papenbrock 27.03.2013 - 19:19
0

Ma table wp_options contenait 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é supprimées automatiquement.

Je ne sais pas s'il s'agit d'un lien ou non, mais j'avais examiné mes fichiers /var/log/apache2/access.log et constaté que plusieurs serveurs (supposément compromis) Amazon Web Services (adresses IP commençant avec 54.XXX et 32.XXX) ont 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 un type de données de type 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 des quantités massives dans le champ option_value. En examinant les résultats, j'ai également constaté des tentatives d'injection de commandes dans le processus wp-cron avec l'espoir qu'elles seraient exécutées au cours du ou des cycles cron.

Ma solution consistait à 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 à partir de wp_options où nom_option est tel que '% transitoire %';

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

    
réponse donnée Ex_Military 07.09.2017 - 03:55

Lire d'autres questions sur les étiquettes