De ce sunt atât de lente actualizările simple în wp_postmeta pentru "_edit_lock"?

Question

De ce sunt atât de lente actualizările simple în wp_postmeta pentru "_edit_lock"?

21 feb. 2014, 19:04:04

Vizualizări: 19.4K

Voturi: 13

În jurnalul nostru de interogări lente MySQL, cea mai lentă interogare cumulativ este o simplă actualizare în wp_postmeta. Iată un exemplu:

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

Detalii relevante despre configurația noastră:

Timpul pentru interogări lente MySQL setat la 1s
Motorul de stocare pentru wp_postmeta este InnoDB
Rulează într-o instalație WordPress Multisite mare cu zeci de mii de articole pe blogul principal WP (unde apar aceste interogări lente)
Activitate ridicată în zona de administrare WP (mulți autori/editori lucrează concomitent, dar în general pe propriul conținut)
Activitate redusă pe partea publică a WP (nu se servește conținut din blogul principal)
Interogările lente par să folosească toate cheia "_edit_lock"; interogări de același format (care folosesc alte chei decât "_edit_lock") nu par să fie lente.

De ce aceasta este cea mai lentă interogare pe sistemul nostru? Are legătură cu modul specific în care WP folosește "edit locks"?

Mulțumesc! :)

Actualizare: Ieșirea din mysqlsla mai jos:

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

rinogo

1.44K

mysql post meta

Comentarii

Câte rezultate obții pentru SELECT * FROM wp_postmeta WHERE meta_key='_edit_lock'; ?

adrian7

22 feb. 2014 13:27:33

Mulțumesc pentru întrebare, adrian7! Există 33k de rânduri care se potrivesc cu interogarea ta. Nu sunt familiarizat cu modul în care WP utilizează cheia meta '_edit_lock'. Este anormal acest lucru?

rinogo

24 feb. 2014 20:09:54

nu este anormal, WordPress o folosește pentru a avertiza utilizatorii când încearcă să editeze același articol/pagină. Sugerez să ștergi toate _edit_lock din wp_postmeta, evident când nimeni nu editează și să verifici după orice îmbunătățiri de performanță. (Apropo, fă mai întâi o copie de rezervă).

adrian7

25 feb. 2014 14:13:34

Durează și o cantitate enormă de timp când doar faci SELECT pentru această intrare? De exemplu SELECT * FROMwp_postmetaWHEREpost_id= 94705 ANDmeta_key= '_edit_lock';?

fischi

5 mar. 2014 02:17:51

@fischi: Acea interogare pare să dureze între 45-50ms, cel puțin în testele pe care le-am făcut acum câteva momente. Totuși, este posibil ca ocazional să dureze foarte mult (de exemplu până la 84 de secunde, așa cum apare în rezultatele mysqlsla incluse în întrebare). Voi rula o nouă analiză a interogărilor lente pentru a vedea dacă modificările recente aduse configurației noastre au afectat interogările.

rinogo

13 mar. 2014 20:52:48

Arată celelalte 5 comentarii

Toate răspunsurile la întrebare

seot 196 · Answer 1 · 2014-04-02T04:25:45Z

_edit_lock este generat de fiecare dată când editezi un articol sau o pagină. Conține timestamp-ul și utilizatorul, astfel WordPress știe cine editează în acel moment.

meta_id     post_id     meta_key    meta_value
9           5           _edit_lock  1388386997:1

Dacă manipulezi această valoare, WordPress poate reacționa destul de sensibil... Am încercat să calculez câte secunde a lucrat cineva la un articol. De fiecare dată mi-a afectat timpul de încărcare al bazei de date.

Cum ai menționat că rulezi un multisite mare. Nu știu câți utilizatori scriu articole acolo, dar cu siguranță poate cauza probleme de RAM pe server dacă prea mulți oameni editează articole în același timp.

O soluție ar putea fi: să elimini _edit_lock

Cum să dezactivezi "Post Lock/Edit Lock"?

În mod normal, WordPress ar trebui să aibă o singură înregistrare "_edit_lock" per articol. Unele baze de date au probleme generându-le de fiecare dată.

Ca în cazul acestui utilizator http://wordpress.org/support/topic/can-i-remove-_edit_lock-_edit_last-from-wp_postmeta

Soluția lui a fost să le șteargă pe toate. Pentru a accelera procesul, poți să le ștergi pe toate în fiecare noapte la ora 3 în phpMyAdmin cu

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

sau poți configura un cron job care să facă exact asta.

demopix 34 · Answer 2 · 2019-09-03T18:09:49Z

încearcă asta :)

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

demopix

34

3 sept. 2019 18:09:49

demopix 34 · Answer 3 · 2020-04-23T10:53:11Z

Probabil, cel mai simplu mod este să folosești metoda WP.

update_post_meta($post_id, '_edit_lock', time().':'.$user_id);

demopix

34

23 apr. 2020 10:53:11