Коли клієнт повідомляє про повільну роботу адміністративної панелі, збої при оформленні замовлення або випадкових таймутах, команда підтримки не має можливості копатися в десятках таблиць або аналізувати поведінку плагінів. Необхідно швидко виявляти можливі точки відмови та зосередитись на ключових вузьких місцях.
На практиці більшість серйозних проблем із продуктивністю та стабільністю пов'язані з невеликою кількістю таблиць бази даних, які безконтрольно розростаються з часом. Ці таблиці не викликають проблем на нових сайтах або сайтах з низькою відвідуваністю, але з роками накопиченого контенту, плагінів та активності користувачів вони стають причиною непропорційно великої кількості збоїв, повільних запитів та звернень до служби підтримки.
У цій статті розглядаються п'ять таблиць бази даних WordPress (і шаблони таблиць), які командам техпідтримки варто регулярно контролювати, оскільки вони найчастіше викликають реальні проблеми з продуктивністю у міру зростання сайтів.
Інформація
У прикладах та скріншотах цієї статті використовується Kinsta Database Studioщо забезпечує прямий доступ до баз даних WordPress з MyKinsta. Концепції, що розглядаються, запити та попереджувальні знаки застосовні незалежно від того, який інструмент для роботи з базами даних ви використовуєте.
Чому достатньо відстежувати лише 20% бази даних?
принцип Парето допомагає пояснити багато операційних закономірностей, і він також застосовується до обслуговування баз даних WordPress. Проблеми виникають нерівномірно по всій базі даних (БД). Натомість, більшість уповільнень, збоїв і термінових звернень до служби підтримки пов'язані з невеликою частиною таблиць.
У стандартних установках WordPress створюється 12 таблиць за промовчанням. Деякі з них, такі як таблиці wp_users, wp_links, і навіть таблиці таксономій, можуть працювати роками без проблем. Зазвичай вони не викликають уповільнення запитів, що веде до збоїв на сайтах під час пікових навантажень.
Однак, таблиці з високим ризиком мають одну спільну рису: вони можуть викликати масштабні збої в роботі сайту. Сайт зі 100 записами може нормально працювати з необмеженою кількістю правок. Той самий сайт із 10 000 записами та 300 000 правками, швидше за все, видаватиме помилку на кожному екрані редагування. Інтернет-магазин із 50 товарами має працювати добре, але при масштабуванні до 5000 товарів сторінки можуть завантажуватись по кілька секунд.
П'ять шаблонів БД, що призводять до збоїв сайтів WordPress у масштабах підприємства
Розглянемо п'ять закономірностей, які найчастіше зустрічаються у роботі з технічного обслуговування.
На невеликих сайтах вони не становлять безпосередньої небезпеки, але в міру збільшення контенту, трафіку та активності плагінів стають найпоширенішими джерелами повільних запитів, таймаутів та проблем зі стабільністю.
wp_options: надмірне автозавантаження може призвести до збою сайтів з високою відвідуваністю
В wp_optionsтаблиці зберігаються параметри сайту та конфігурації плагінів, а також визначається, які параметри WordPress завантажує при кожному запиті сторінки (включаючи кешовані сторінки). Серед стовпців найважливішим є стовпець «autoload»:
WordPress спочатку завантажує всі параметри, що автоматично завантажуються в пам'ять при кожному запиті. Сайти з меншим обсягом автоматично завантажуваних параметрів можуть нормально обробляти трафік, хоча в міру збільшення обсягу параметрів, що автоматично завантажуються, кожен відвідувач споживає більше пам'яті, ніж сервер виділяє кожному процесу PHP.
Якщо розмір файлів, що автоматично завантажуються, стає занадто великим (наприклад, перевищує 3 МБ), ви можете зіткнутися з повільною роботою адміністративної панелі, збоями при оформленні замовлення та помилками 502.
Винуватцем майже завжди є "осиротілі" налаштування плагінів або тимчасові записи кешу, відомі як "транзієнти". При увімкненому автозавантаженні деякі віддалені вами параметри плагіна можуть залишитися в wp_optionsтаблиці, а це означає, що вони завантажуватимуться при кожному запиті. У десятках плагінів протягом місяців або років це призводить до накопичення "осиротілих" даних, які завантажуються при кожному перегляді сторінки.
Наведена вище консоль SQL в Database Studio дозволяє виконати запит для перевірки розміру даних, що автоматично завантажуються в байтах:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes' UNION SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes' UNION (SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Ви також можете використовувати консоль для виконання інших необхідних запитів, наприклад, для сортування результатів початкового запиту.
Ваш план тут повинен полягати в тому, щоб проаналізувати результати, визначити, до яких великих записів автозавантаження вони належать, та очистити їх (тобто видалити рядки).
wp_postmeta: Сайти електронної комерції можуть давати збої через роздування метаданих
В wp_postmeta таблиці зберігаються поля користувача для записів, сторінок і товарів. При кожному збереженні вмісту можна додавати нові записи метаданих. Плагіни, зокрема, часто прикріплюють до одного запису чи товару десятки полів.
Наприклад, WooCommerce зберігає дані про товари в postmeta: варіанти, наявність на складі, інформація про доставку та атрибути. Один товар із варіантами може генерувати десятки записів метаданих. Великі каталоги товарів створюють потенційно мільйони рядків postmeta.
В результаті роздування wp_postmetaтаблиці виникають проблеми із завантаженням даних на екранах редагування, уповільнення роботи фільтрів товарів та таймати пошуку при спробі виконати запит до великих таблиць. Як правило, помилки в періоди високого навантаження зазвичай пов'язані з wp_postmeta роздмухуванням таблиці.
За допомогою консолі SQL можна виконувати запити для вибору та видалення надлишкових даних, подібних до цих wp_options. Вам потрібні такі елементи, як багатогігабайтні таблиці postmeta, велика кількість дублікатів meta_keys і загальні "осиротілі" метадані. Параметри фільтрації в Database Studio також виявляться корисними тут:
Наприклад, ви можете відсортувати дані meta_key, клацнувши стрілку стовпця. Це згрупує однакові ключі разом, щоб ви могли виявити закономірності, такі як ключі з віддалених плагінів або поля, що не використовуються.
wp_posts: необмежену кількість правок призводить до збою екрана редагування
В wp_postsтаблиці зберігається контент та історія змін. За промовчанням WordPress зберігає кожну зміну як окремий запис у базі даних, тому регулярне редагування контенту генерує значний обсяг додаткових даних. На сайтах із великою історією контенту та редагування можуть накопичуватися тисячі записів про зміни.
Спочатку сайти працюють нормально, але велика кількість збережених версій може призвести до повільного завантаження адміністративної панелі під час редагування записів. WordPress зберігає зміни кожні 60 секунд під час редагування; автозбереження може негативно позначитися, оскільки тривалі сеанси редагування створюють десятки записів автозбереження.
Ви можете швидко відфільтрувати wp_postsтаблицю правок (наприклад):
Потім можна перейти в консоль SQL, щоб виконати запит і видалити зміни:
DELETE FROM wp_posts WHERE post_type="revision";
Варто порівняти кількість правок із кількістю опублікованих записів: співвідношення «1 запис: до 5–10 ревізій» зазвичай допустиме. Також перевірте, чи складають редагування більше половини від загального числа записів, оскільки це може вказувати на роздування контенту. Збільшення кількості правок з місяця на місяць говорить про необхідність введення обмежень, чого можна досягти за допомогою редагування файлуwp-config.php.
Таблиці плагінів: форми та журнали розростаються доти, доки ваші сайти не впадуть
Практично кожен плагін створює власні таблиці бази даних, але це частіше зустрічається в плагінах для форм, пошуку та безпеки. Такі таблиці можуть постійно розширюватись, не вимагаючи вбудованого обслуговування.
Зокрема, плагіни форм за замовчуванням зазвичай зберігають кожну відправлену форму назавжди. Таким чином, якщо ваші сайти отримують стабільний трафік форм протягом багатьох років, ви накопичуєте тисячі форм записів. Більше того, таблиці, пов'язані з логами, зростають ще швидше. Плагіни безпеки реєструють дії відвідувачів, плагіни аналітики відстежують перегляди сторінок, а інструменти налагодження записують помилки.
Як і у багатьох випадках із проблемами таблиць бази даних, відбувається таймати завантаження сторінок. Але також спостерігаються уповільнення резервного копіювання бази даних та зниження продуктивності, що не корелює з обсягом трафіку. Зв'язок із роздуванням бази даних який завжди очевидна, оскільки симптоми виявляються у незв'язаних областях.
Вам слід пошукати таблиці плагінів, розміри яких відповідають чи перевищують розміри основних таблиць WordPress; що більше вони, то важливіше їх зменшити. SQL-запит допоможе їх виявити:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC; Якщо якісь із цих таблиць є "осиротілими", то можна сміливо їх видалити. Однак, хоча це виходить за рамки цієї статті, якщо таблиці розрослися до критичного розміру, але вони, як і раніше, необхідні на вашому сайті, вам слід вивчити інформацію про них, можливо, зв'язавшись з розробником для отримання консультації.
Планувальник дій: невдалі завдання накопичуються та призводять до збою під час оформлення замовлення
По суті, Планувальник дій запуск фонових завдань для WordPress. Він ставить завдання у чергу, обробляє їх асинхронно і постійно зберігає записи про завершення.
Використання WooCommerce – чудовий спосіб зрозуміти, як планувальник дій може викликати проблеми. Наприклад, тайм-аути платіжного шлюзу призводять до збоїв у виконанні дій, які зберігаються в БД та перевіряються при кожному завантаженні сторінки на наявність незавершених завдань. Ви можете виділити лише одну невдало виконану задачу з тисяч, яку генерує типовий магазин WooCommerce на місяць.
Функція «Уявлення» у Database Studio допоможе видалити ці невдалі дії:
Тут задайте заголовок вистави, виберіть таблицю wp_actionscheduler_actions, а потім натисніть посилання «Додати умову». Це дозволить відображати лише невдалі дії, що спростить їх видалення з бази даних.
Як контролювати критичні таблиці WordPress за 10 хвилин на місяць
Витративши лише кілька хвилин на місяць, ви зможете скоротити обсяг роботи з управління базою даних протягом року. Звичайно, вам не потрібно буде відстежувати чи керувати багатьма таблицями у вашій базі даних:
wp_usersтаблиця рідко викликає проблеми, якщо ви не керуєте сайтами з членством, що налічують мільйони облікових записів. Обсяг даних користувача зазвичай зростає лінійно, не призводячи до роздування даних.- Таблиці таксономії (такі як
wp_terms,wp_term_taxonomy,wp_term_relationships) часто залишаються стабільними незалежно від розміру сайту.
Серед п'яти проблемних таблиць, великі wp_postsтаблиці на контентних сайтах є типовими та очікуваними. Пам'ятайте: великий обсяг контенту сам не вважається роздуванням бази.
Налаштування робочого процесу моніторингу
Експорт таблиць бази даних дозволяє працювати з даними в інших програмах. Це можна зробити за допомогою меню « Додаткові елементи » (три крапки) для будь-якої таблиці:
До найбільших таблиць належать wp_posts, wp_postmeta, І wp_options. Слід вивчити всі таблиці, що посідають вищі позиції у рейтингу.
Конкретні параметри моніторингу, які ви налаштуєте, залежать від сайтів та потреб. Однак є кілька областей, на які варто звернути увагу:
- Відфільтруйте файли
wp_optionsза активними автозавантаженнями, потім перевірте загальний розмір (за допомогою SQL-запитів або експорту до CSV). Усі, що перевищує 1 МБ, слід перевірити. - Порівняйте
wp_postmetaРозмір таблиці з даними за минулий місяць, особливо якщо йдеться про значне збільшення розмірів. - Ви можете використовувати фільтр post_type для
wp_postsпорівняння версій із записами. У разі потреби встановіть обмеження в налаштуванняхwp-config.php. - У планувальнику дій кількість виконаних дій повинна перевищувати кількість дій, що очікують або невдало завершені.
Порада: Команда WP-CLI wp transient delete допоможе видалити застарілі тимчасові дані.
Від оперативного усунення несправностей до проактивного обслуговування баз даних
Проблеми з базами даних є рідкісними або непередбачуваними. Вони є результатом знайомих закономірностей. Різниця між реагуванням на ці проблеми та їх запобіганням зводиться до концентрації уваги.
Не потрібно перевіряти кожну таблицю чи проводити аудит кожного запиту. Необхідно знати, які частини бази даних заслуговують на постійну увагу і як виявляти ранні ознаки проблем до того, як вони переростуть у збої або екстрені запити до служби підтримки.
Для організацій, що займаються технічним обслуговуванням, це змінює підхід до роботи з базами даних. Замість розглядати очищення бази даних як разове рішення після поломки, вона стає простою і повторюваною перевіркою.
Джерело: kinsta.com
Коментарі до запису: 0