web-dev-qa-db-fra.com

Pourquoi les simples mises à jour de wp_postmeta "_edit_lock" sont-elles si lentes?

Dans notre journal de requête lente MySQL, la requête la plus lente cumulative 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:

  • Temps de requête lente MySQL défini à 1s
  • le moteur de stockage de wp_postmeta est InnoDB
  • Exécution dans une grande installation multisite avec des dizaines de milliers de messages sur le blog principal WP (où ces requêtes lentes se produisent)
  • Forte activité dans le domaine WP admin (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 sert pas réellement 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 être lentes.

Pourquoi est-ce que c'est 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         :
        xxx_wp@localhost  : 98.84% (599) of query, 51.03% (1837) of all users
        yyy_wp@localhost  : 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';
post-metamysqlupdate-post-meta
11
rinogo

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 post. Tout le temps il cassé mon temps de chargement de base de données.

Comme vous l'avez dit, vous utilisez ceci sur un grand multisite. Je ne sais pas combien d'utilisateurs écrivent des messages, mais cela pourrait définitivement casser le RAM du serveur si plusieurs personnes modifiaient un message en même temps.

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

Comment désactiver le "Post Lock/Edit Lock"?

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 gars http://wordpress.org/support/topic/can-i-remove-_edit_lock-_edit_last-from-wp_postmeta

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'

vous trouvez peut-être un travail cron qui fait exactement cela.

3
seot