База данных WordPress (MyISAM) работает медленно, стоит ли переходить на InnoDB?

24 февр. 2011 г., 13:34:44
Просмотры: 15.3K
Голосов: 16

У меня есть сайт на WordPress с более чем 10 тыс. записей, и при добавлении или редактировании постов всё начинает работать очень медленно. Страницы загружаются быстро для пользователей, как и списки записей в админке, но когда происходят операции записи или обновления, сервер загружает CPU на 100%, и это занимает много времени (иногда дольше таймаута PHP в 60 секунд).

Я предполагаю, что это связано с блокировками на уровне таблиц в MyISAM, и думаю о переходе на InnoDB. Каковы последствия такого перехода?

Некоторые статистические данные:

select  - в час ~22 тыс.
update  - в час ~7.6 тыс.
set option  - в час ~7 тыс.

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

Спасибо.

Обновление: Я обнаружил одну из основных причин замедления — это плагин YARPP (Yet Another Related Posts Plugin), который пересчитывал "схожесть" каждый раз, и, похоже, это было связано с 2 тыс.+ тегами на сайте. Я отключил опцию "учитывать теги", и это значительно ускорило работу.

Кроме того, другие плагины, которые пересоздают данные (например, некоторые плагины XML-карт сайта), могут вызывать подобные проблемы.

Таким образом, моя текущая проблема решена, но я всё равно хотел бы услышать хороший ответ по поводу выбора между InnoDB и MyISAM для WordPress!

0
Все ответы на вопрос 2
3
14

Я определенно перешел бы на InnoDB. Вопрос блокировок таблиц/строк давно обсуждается многими. Я без колебаний всегда выбираю InnoDB. Однако есть еще одна веская причина выбрать InnoDB... КЭШИРОВАНИЕ.

В то время как многие хвастаются, что MyISAM быстрее для чтения, большинство забывает, что его кэш, называемый key cache (управляется параметром key_buffer_size), кэширует только индексные страницы из .MYI файлов. Он никогда не кэширует страницы данных. Официальный максимум составляет 4 ГБ в 32-битных системах. Лучший максимум для 64-битных — 8 ГБ.

Буферный пул InnoDB кэширует как данные, так и индексные страницы. В зависимости от сервера вы можете кэшировать весь набор данных в оперативной памяти. Вы можете настроить InnoDB на использование до 80% ОЗУ, 10% оставить для соединений с БД, и 10% для операционной системы. Это справедливо даже для разных операционных систем.

Я рекомендовал эти настройки клиентам, использующим Drupal, с потрясающим успехом. Это в равной степени применимо и к WordPress. Я оказывал поддержку по настройке БД для клиентов с WordPress. Те же улучшения.

Вы всегда можете настроить память для InnoDB более эффективно, чем для MyISAM. Всегда есть способ оптимизировать InnoDB под ваши потребности в производительности. По мере роста ваших данных это в конечном итоге станет необходимостью.

22 апр. 2011 г. 05:19:59
Комментарии

Это как-то относится к нам, простым смертным, у которых shared hosting, файлы на одном сервере, а база данных на другом, и наш хостинг не особо прозрачен в том, сколько ресурсов нам доступно? Мы настраиваем сервер через наши скрипты или фактически настраиваем сам сервер?

pathfinder pathfinder
11 июн. 2022 г. 07:38:32

Безусловно, это абсолютно применимо. Вы можете получить более реалистичное представление о ресурсах, зная ограничения, которые shared hosting на вас накладывает. В свете этого, улучшение производительности БД потребует хорошо спланированного единоразового преобразования для реорганизации использования ресурсов MySQL, а не увеличения ресурсов операционной системы.

RolandoMySQLDBA RolandoMySQLDBA
11 июн. 2022 г. 14:12:28

Спасибо @RolandoMySQLDBA. Я глубже изучил некоторые из ссылок и сделал именно это. Оно того стоило. Значительный прирост скорости :)

pathfinder pathfinder
12 июн. 2022 г. 16:11:48
0

InnoDB, скорее всего, вам не поможет - блокировки на уровне страниц/строк помогают снизить конкуренцию, но похоже, что это не ваша проблема.

Существует множество данных, указывающих на то, что MyISAM работает медленнее InnoDB в типичном блог-сценарии (гораздо больше операций чтения, чем записи).

Прежде чем переключаться, вам следует как минимум сделать следующее:

  • запустить mysqltuner, который даст вам рекомендации по конфигурации (хотя он не безошибочен и не всезнающ)
  • включить лог медленных запросов, оставить его на день или около того, а затем начать анализировать логи и использовать EXPLAIN для запросов, чтобы понять, что происходит

Из личного опыта я обнаружил, что добавление индекса к неиндексированному полю в wp_comments значительно помогло в моей конкретной ситуации (периоды всплесков комментирования, когда 10 или более человек могли пытаться оставить комментарий одновременно). Возможно, выяснение того, какие запросы выполняются медленно и почему, приведёт вас к лучшему пониманию проблемы и НАСТОЯЩЕМУ решению!

2 мар. 2011 г. 12:23:35