Чому прості оновлення для "_edit_lock" wp

У нашому журналі повільних запитів MySQL, кумулятивно повільний запит - це просте оновлення до wp_postmeta. Ось приклад:

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

Релевантні відомості про наше налаштування:

Час повільного запиту MySQL встановлено у 1 с
Двигун зберігання wp_postmeta - InnoDB
Запуск у великій установці Multisite з десятками тисяч публікацій на головному блозі WP (де ці повільні запити відбуваються)
Висока активність в області адміністрування WP (багато авторів / редакторів працюють одночасно, але загалом над власним (не чужим) вмістом)
Низька активність на публічній стороні WP (фактично не розміщується вміст з основного блогу)
Здається, для повільних запитів використовується клавіша "_edit_lock"; запити того самого формату (які використовують ключ, відмінний від "_edit_lock"), здається, не повільні.

Чому це найповільніший запит у нашій системі? Чи має щось спільне зі специфічним використанням WP "редагування замків"?

Спасибі! :)

Оновлення: вихід з mysqlsla нижче:

______________________________________________________________________ 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

— риного
джерело

Скільки результатів ви отримуєте SELECT * FROM wp_postmeta WHERE meta_key='_edit_lock'; ?

— adrian7

Дякую за запитання, adrian7! Є 33k рядків, що відповідають вашому запиту. Я не знайомий з використанням WP мета-ключа '_edit_lock'. Це ненормально?

— rinogo

це не ненормально, wordpress використовує це для попередження користувачів, коли вони намагаються редагувати ту саму допис / сторінку. Я пропоную вам видалити всі _edit_locks з wp_postmeta, очевидно, коли немає жодного редагування та перевірки після покращення продуктивності. (BTW спочатку зробить резервну копію).

— adrian7

Чи це також займає величезну кількість часу, коли ви просто SELECTцей запис? Як SELECT * FROM wp_postmeta `WHERE post_id= 94705 AND meta_key= '_edit_lock';`?

— fischi

@fischi: Здається, цей запит займає 45-50 мс, принаймні на тестуванні, яке я робив декілька моментів тому. Однак можливо, що це може зайняти дуже тривалий час (наприклад, до 84 секунд, як показано у висновку mysqlsla, включеному у запитання). Я проведу новий раунд повільного аналізу запитів, щоб побачити, чи якісь мої останні зміни в нашій конфігурації вплинули на запити.

— rinogo

_edit_lock створюється щоразу, коли ви редагуєте публікацію чи сторінку. він складається з часового коду та користувача. тож WordPress знає, хто зараз його редагує.

meta_id     post_id     meta_key    meta_value
9           5           _edit_lock  1388386997:1

якщо ви маніпулюєте нею, WordPress реагує якось чутливо ... Я намагався зрозуміти, скільки секунд хтось працював над публікацією. Я весь час порушував час завантаження моєї бази даних.

Як ви вже говорили, ви працюєте на великому мультисайті. Не знаю, скільки користувачів записують там публікації, але це однозначно може порушити оперативну пам’ять сервера, якщо багато людей одночасно редагують публікацію.

Рішенням може бути: позбутися _edit_lock

Як відключити "Заблокувати повідомлення / змінити блокування"?

Зазвичай WordPress повинен мати "_edit_lock" один за повідомлення. У деяких базах даних виникає проблема їх генерування кожного разу.

Як цей хлопець http://wordpress.org/support/topic/can-i-remove-_edit_lock-_edit_last-from-wp_postmeta

Його рішення полягало в тому, щоб видалити їх усіх. Щоб пришвидшити його, ви можете видаляти їх щовечора о 3 годині в phpMyAdmin за допомогою

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

можливо, ви знайдете роботу з хроном саме так.

— seot
джерело

спробуйте це :)

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

— демопікс
джерело

Чому прості оновлення для "_edit_lock" wp_postmeta так повільні?