Таблицы базы данных WordPress, вызывающие проблемы с производительностью сайта

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

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

В этой статье рассматриваются пять таблиц базы данных 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; 

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

Планировщик действий: неудачные задачи накапливаются и приводят к сбою при оформлении заказа

По сути, Action Scheduler запускает фоновые задачи для 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

Алексей Шевченко

редактор wpcafe

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующийся на создании сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/