Почему простые обновления wp_postmeta "_edit_lock" выполняются так медленно?

21 февр. 2014 г., 19:04:04
Просмотры: 19.4K
Голосов: 13

В нашем логе медленных запросов 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-установке с десятками тысяч записей в основном блоге WordPress
  • Высокая активность в админке WordPress
  • Низкая активность на публичной стороне
  • Медленные запросы используют только ключ "_edit_lock"

Почему этот запрос самый медленный? Это связано с блокировками редактирования в WordPress?


Обновление: Вывод из 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';
10
Комментарии

Сколько результатов вы получаете для запроса SELECT * FROM wp_postmeta WHERE meta_key='_edit_lock'?

adrian7 adrian7
22 февр. 2014 г. 13:27:33

Спасибо за ваш вопрос, adrian7! Запрос возвращает 33 тысячи строк. Я не знаком с использованием WordPress мета-ключа '_edit_lock'. Это ненормально?

rinogo rinogo
24 февр. 2014 г. 20:09:54

Это нормально, WordPress использует его для предупреждения пользователей, когда они пытаются редактировать одну и ту же запись/страницу. Я рекомендую вам удалить все записи _edit_lock из таблицы wp_postmeta, очевидно, когда никто не редактирует записи, и проверить, улучшится ли производительность. (Кстати, сначала сделайте резервную копию).

adrian7 adrian7
25 февр. 2014 г. 14:13:34

Занимает ли также огромное количество времени, когда вы просто делаете SELECT этой записи? Например SELECT * FROMwp_postmetaWHEREpost_id= 94705 ANDmeta_key= '_edit_lock';?

fischi fischi
5 мар. 2014 г. 02:17:51

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

rinogo rinogo
13 мар. 2014 г. 20:52:48

Похоже, что мы до сих пор получаем медленные запросы такого типа... Самое странное, что наш сервер в целом относительно свободен. Мы используем VPS с 8 процессорами, текущая нагрузка 0.27 0.51 0.66 и стабильный процент попаданий в кеш InnoDB 100%. Я думаю, большинство согласится, что это, скорее всего, не проблема с самим SQL, генерируемым Wordpress, а скорее с базовой архитектурой и тем, как она взаимодействует с базой данных (MySQL). Похоже, здесь происходит что-то странное, что глубже, чем просто оптимизация SQL-запросов и подобное...

rinogo rinogo
13 мар. 2014 г. 21:28:08

http://bugs.mysql.com/bug.php?id=28382 может быть связан. Уменьшение кэша запросов может помочь.

fuxia fuxia
14 мар. 2014 г. 04:22:00

Хм... Возможно. Этот баг является дубликатом http://bugs.mysql.com/bug.php?id=21074, который, похоже, закрыт и включен в версию 5.1.23. У нас запущена версия 5.1.73. :/ В любом случае, стоит попробовать - думаю, можно поэкспериментировать с разными размерами кэша/буфера, чтобы увидеть, есть ли явная связь. В любом случае, эта проблема точно не останавливает нашу систему; это скорее желтый флажок. Возможно, то, что это всплывает, связано с нашим избытком ресурсов и рвением в охоте за медленными запросами и их устранении...? Тем не менее, что-то странное определенно происходит.

rinogo rinogo
14 мар. 2014 г. 06:04:56

(то есть, возможно, как вы предполагаете, выделение большего количества ресурсов на проблему И является источником самой проблемы...)

rinogo rinogo
14 мар. 2014 г. 06:05:58

Прежде всего, необходимо проверить конфигурации вашего сервера для обеспечения производительности и оптимального использования. WordPress с таким большим объемом данных и структурой сам по себе может работать очень медленно. Иногда могут возникать сбои MySQL или другие проблемы на стороне сервера. Если вы ограничите доступ к вашему серверу или странице одним пользователем за раз, это может ускорить работу. Проблема заключается в стороне сервера, а не в WordPress. Перенесите вашу MySQL на отдельный VPS, а страницу на другой, используйте облачные сервисы, SSD-диски на сервере, увеличьте объем оперативной памяти на сервере. Только после этого можно объективно тестировать запросы.

Foxsk8 Foxsk8
14 мар. 2014 г. 23:47:36
Показать остальные 5 комментариев
Все ответы на вопрос 3
0

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

Возможно, вы найдете подходящее задание для cron, которое будет выполнять эту операцию автоматически.

2 апр. 2014 г. 04:25:45
0

попробуйте это :)

UPDATE `wp_postmeta` 
    SET `meta_value` = concat(unix_timestamp(),':386')  
    WHERE `post_id`  = 94705 
      AND `meta_key` = '_edit_lock';
3 сент. 2019 г. 18:09:49
0

Возможно, самый простой способ — использовать метод WordPress.

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

23 апр. 2020 г. 10:53:11