Pourquoi les mises à jour simples du «_edit_lock» de wp_postmeta sont-elles si lentes?

10

Dans notre journal de requête lente MySQL, la requête la plus lente au cumul est une simple mise à jour de wp_postmeta. Voici un exemple:

UPDATE 'wp_postmeta'
  SET 'meta_value' = '1392835505:386'
  WHERE 'post_id' = 94705 AND 'meta_key' = '_edit_lock';

Détails pertinents sur notre configuration:

  • Le temps de requête lente de MySQL est défini sur 1s
  • Le moteur de stockage de wp_postmeta est InnoDB
  • Exécution dans une grande installation multisite avec des dizaines de milliers de publications sur le blog principal de WP (où se produisent ces requêtes lentes)
  • strong activité dans la zone d’administration de WP (de nombreux rédacteurs / éditeurs travaillent simultanément, mais généralement sur leur propre contenu (pas celui des autres))
  • Faible activité du côté public de WP (ne pas diffuser le contenu du blog principal)
  • Les requêtes lentes semblent toutes utiliser la clé "_edit_lock"; Les requêtes du même format (utilisant une clé autre que "_edit_lock") ne semblent pas lentes.

Pourquoi s’agit-il de la requête la plus lente sur notre système? Cela a-t-il quelque chose à voir avec l'utilisation spécifique par WP de "edit locks"?

Merci! :)

Mise à jour: sortie de mysqlsla ci-dessous:

______________________________________________________________________ 001 ___
Count         : 606  (16.83%)
Time          : 2257.760468 s total, 3.725677 s avg, 1.00512 s to 84.645869 s max  (20.60%)
  95% of Time : 1355.289277 s total, 2.357025 s avg, 1.00512 s to 12.343604 s max
Lock Time (s) : 182.502 ms total, 301 μs avg, 29 μs to 157.542 ms max  (0.21%)
  95% of Lock : 22.882 ms total, 40 μs avg, 29 μs to 57 μs max
Rows sent     : 0 avg, 0 to 0 max  (0.00%)
Rows examined : 1 avg, 1 to 2 max  (0.00%)
Database      : xxx_wp
Users         :
        [email protected]  : 98.84% (599) of query, 51.03% (1837) of all users
        [email protected]  : 1.16% (7) of query, 0.94% (34) of all users

Query abstract:
SET timestamp=N; UPDATE wp_postmeta SET meta_value = 'S' WHERE post_id = N AND meta_key = 'S';

Query sample:
SET timestamp=1392835506;
UPDATE 'wp_postmeta' SET 'meta_value' = '1392835505:386' WHERE 'post_id' = 94705 AND 'meta_key' = '_edit_lock';
    
posée rinogo 21.02.2014 - 18:04

1 réponse

2

le _edit_lock est généré chaque fois que vous modifiez un article ou une page. il se compose du code temporel et de l'utilisateur. WordPress sait donc qui le modifie actuellement.

meta_id     post_id     meta_key    meta_value
9           5           _edit_lock  1388386997:1

Si vous le manipulez, WordPress réagit de façon sensible. J'ai essayé de chercher combien de secondes quelqu'un avait travaillé sur un message. Tout le temps il a cassé le temps de chargement de ma base de données.

Comme vous l'avez dit, vous exécutez ceci sur un grand multisite. Je ne sais pas combien d’utilisateurs écrivent des messages, mais cela pourrait casser la mémoire vive du serveur si, pour un grand nombre de personnes, modifiait une publication en même temps.

Une solution pourrait être: se débarrasser de _edit_lock

Comment désactiver le "Verrouillage post / verrouillage" ?

Normalement, WordPress devrait avoir le "_edit_lock" un par Post. Certaines bases de données ont le problème de les générer à chaque fois.

comme ce mec enlace

Sa solution était de les supprimer tous. Pour accélérer le processus, vous pouvez tous les supprimer tous les soirs à 3 heures dans phpMyAdmin avec

.
DELETE FROM 'yourdb'.'wp_postmeta' WHERE 'wp_postmeta'.'meta_key' = '_edit_lock'

Peut-être trouvez-vous un travail cron faisant exactement cela.

    
réponse donnée seot 02.04.2014 - 03:25

Lire d'autres questions sur les étiquettes