Pourquoi les mises à jour simples du «_edit_lock» de wp

Dans notre journal des requêtes lentes MySQL, la requête cumulativement la plus lente 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 lent MySQL défini sur 1 s
Le moteur de stockage de wp_postmeta est InnoDB
Fonctionnant dans une grande installation multisite avec des dizaines de milliers de messages sur le blog principal de WP (où ces requêtes lentes se produisent)
Forte activité dans la zone d'administration de WP (beaucoup d'écrivains / éditeurs travaillant simultanément, mais généralement sur leur propre contenu (pas sur celui des autres))
Faible activité du côté public de WP (ne servant pas réellement le contenu du blog principal)
Les requêtes lentes semblent toutes utiliser la touche "_edit_lock"; les requêtes du même format (qui utilisent une clé autre que "_edit_lock") ne semblent pas être lentes.

Pourquoi est-ce la requête la plus lente sur notre système? Cela a-t-il quelque chose à voir avec l'utilisation spécifique par WP des «verrous d'édition»?

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

mysql post-meta

— rinogo
source

Combien de résultats obtenez-vous SELECT * FROM wp_postmeta WHERE meta_key='_edit_lock'; ?

— adrian7

Merci pour votre question, adrian7! Il y a 33k lignes correspondant à votre requête. Je ne suis pas familier avec l'utilisation par WP de la méta-clé '_edit_lock'. Est-ce anormal?

— rinogo

ce n'est pas anormal, wordpress l'utilise pour alerter les utilisateurs lorsqu'ils essaient de modifier le même message / page. Je vous suggère de supprimer tous les _edit_locks de wp_postmeta, évidemment quand il n'y a personne pour éditer et vérifier après toute amélioration des performances. (BTW fait d'abord une sauvegarde).

— adrian7

Cela prend-il aussi énormément de temps lorsque vous venez de SELECTcette entrée? Comme SELECT * FROM wp_postmeta` WHERE post_id= 94705 AND meta_key= '_edit_lock'; `?

— fischi

@fischi: Cette requête semble prendre de 45 à 50 ms, au moins dans les tests que je viens de faire il y a quelques instants. Cependant, il est possible que cela prenne parfois très longtemps (par exemple jusqu'à 84 secondes, comme indiqué dans la sortie mysqlsla incluse dans la question). Je vais exécuter une nouvelle série d'analyses de requêtes lentes pour voir si l'une de mes modifications récentes de notre configuration a affecté les requêtes.

— rinogo

le _edit_lock est généré chaque fois que vous modifiez un article ou une page. il s'agit du timecode 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 d'une manière ou d'une autre sensible ... J'ai essayé de récupérer combien de secondes quelqu'un a travaillé sur un post. Tout le temps, cela cassait le temps de chargement de ma base de données.

Comme vous l'avez dit, vous exécutez cela sur un grand multisite. Je ne sais pas combien d'utilisateurs écrivent des articles là-bas, mais cela pourrait certainement casser la mémoire RAM du serveur si de nombreuses personnes modifiaient un article 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 un "_edit_lock" par publication. Certaines bases de données ont du mal à 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 l'accélérer, vous pouvez les supprimer tous les soirs à 3 heures dans phpMyAdmin avec

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

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

— seot
source

essaye ça :)

UPDATE `wp_postmeta` 
    SET `meta_value` = concat(unix_timestamp(),':386')  
    WHERE `post_id`  = 94705 
      AND `meta_key` = '_edit_lock';

— demopix
source

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