База даних Wordpress повільно - я повинен перейти на InnoDB?

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

Я думаю, що це, ймовірно, пов'язане з блокуванням рівня таблиці в MyISAM, і я думаю про переключення цього на InnoDB. Які наслідки цього робити?

Деякі статистичні дані:

select  - per hour ~22k
update  - per hour ~7.6k
set option  - per hour ~7k

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

Спасибі

Редагувати : Я виявив одну з головних проблем, що спричиняють повільність, саме YARPP (ще один плагін з пов’язаними повідомленнями) щоразу відновлював "спорідненість", і це, здавалося, було пов’язано з 2k + тегами, які ми маємо. Я вимкнув опцію "розглянути теги", і вона значно скоротилася.

Крім того, інші плагіни, які відновлюють речі, можуть спричинити подібні проблеми, такі як деякі XML плагіни мапи сайту.

Отже, моя негайна проблема вирішена, хоча я все ще хотів би почути гарну відповідь на InnoDB проти MyISAM для Wordpress!

Я б дійсно перейшов на InnoDB. Блокування таблиць / блокування рядків вже давно обговорюється багатьма. Я б завжди вибирав InnoDB руками вниз. Однак є ще одна глибока причина вибору InnoDB ... КАЧІННЯ .

Хоча більшість людей похвалиться тим, що MyISAM швидше читає, більшість людей забувають, що багато кеш-пам'яті для MyISAM, який називається кеш-ключем (встановлений key_buffer_size), кешують лише індексні сторінки з файлів .MYI. Він ніколи не кешує сторінки даних. Він має офіційний максимум 4 Гб в 32-бітних системах. 8 ГБ - найкращий максимум для 64-розрядних.

Пул буфера InnoDB кешує сторінки даних та покажчики. Залежно від вашого сервера, ви можете кешувати до всього набору даних в оперативній пам'яті. Ви можете налаштувати InnoDB до 80% оперативної пам’яті та 10% для скорочення БД, а 10% залишити для ОС. Це справедливо навіть для різних операційних систем .

Я рекомендував ці речі для клієнтів Drupal з надзвичайним успіхом. Це стосується і Wordpress так само добре. Я забезпечив підтримку БД для клієнтів з WordPress. Такі ж поліпшення.

Ви завжди можете налаштувати пам'ять для InnoDB ефективніше, щоб ви могли більше MyISAM. Завжди є спосіб налаштувати InnoDB відповідно до ваших потреб . Коли ваші дані зростають, вони з часом стануть необхідною умовою .

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

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

Перш ніж зробити перемикач, слід принаймні зробити наступне

• запустіть mysqltuner, який дасть вам поради щодо конфігурації (це не непогрішно або все, що відомо)
• увімкніть повільний журнал запитів, залиште його на день або близько того, а потім починайте просіювати журнал і ПОЯСНЕНО запити, щоб побачити, що відбувається

З особистого досвіду я виявив, що додавання індексу до невпорядкованого поля на wp_comments масово допомогло в моїй конкретній ситуації (періоди бурхливих коментування, де 10 або більше людей могли б намагатися прокоментувати одночасно), і можливо, що дізнаєтесь які запити працюють повільно і чому можуть привести вас до кращого розуміння проблеми та РЕАЛЬНОГО рішення!