- Вопрос или проблема
- Сердцебиение администратора
- Обновления базы данных
- Снижайте нагрузку на базу данных
- Проверьте ваши параметры
- Ответ или решение
- Проблема с превышением числа соединений в MySQL: анализ и рекомендации
- 1. Время существования соединений
- 2. WordPress Heartbeat API
- 3. Пиковые нагрузки во время публикации
- 4. Ресурсы сервера базы данных
- 5. Внедрение кэширования
- Заключение
Вопрос или проблема
Мы ведем блог с высокой посещаемостью, на котором одновременно около 500 пользователей и 10000 постов. Мы хостим его на VPS – 16 ГБ, 4 ядра с отдельным сервером базы данных MySQL – 4 ГБ, 2 ядра; оба SSD. С сервером хостинга проблем нет. Однако сервер базы данных иногда исчерпывает количество подключений, хотя у нас есть более чем достаточный лимит в 312 максимальных подключений. У нас нет ненужных плагинов, а максимальное время выполнения составляет около 5 минут. У кого-нибудь есть идеи, что может быть причиной проблемы? 
Больше информации: Мы могли бы сопоставить, что в дни, когда наши блогеры (максимум 10) работают из нашего офиса под одним IP и с медленным – прерывистым сетевым соединением, эта проблема возникает чаще. Проблема возникает чаще в часы пик публикаций, чем в часы простоя.
Или сервер базы данных исчерпывает оперативную память, что в конечном итоге вызывает отключение подключений. Поисковые движки обычно используют больше CPU, но боты не устанавливают более 30 подключений к базе данных, и наши серверы совершенно нормальны в обработке ботов.
Также проблема часто возникает, когда один администратор долгое время оставляет посты в режиме редактирования.
Детали конфигурации wp
‘WP_MEMORY_LIMIT’, ‘256M’; ‘AUTOSAVE_INTERVAL’, 160; максимальное время выполнения 500
Наш монитор запросов имеет некоторые предупреждения о устаревании PHP 7.2, хотя тема стабильная с некоторыми медленными запросами, также ревизии постов жизненно важны для нас.
Это ни в коем случае не будет окончательным ответом, но у меня есть некоторые советы, которые длиннее, чем позволят комментарии.
Меня беспокоит такое высокое максимальное время выполнения. Корень вашей проблемы, вероятнее всего, не связан с количеством подключений к базе данных, а больше с тем, сколько времени эти подключения активны.
Вот несколько моментов, на которые стоит обратить внимание:
Сердцебиение администратора
Вы упомянули большое количество редакторов онлайн одновременно. API Сердцебиения срабатывает каждые 15 секунд и может записывать в базу данных каждый раз для каждого пользователя, в зависимости от ваших настроек и активности пользователя.
Проверьте ваш интервал сердцебиения и количество хранимых ревизий. Я вижу, что вы уже настроили интервал автосохранения.
Обновления базы данных
Записи в базе данных являются одними из самых ресурсоемких для MySQL. Чем больше запросов на запись, особенно одновременно, тем выше нагрузка. Если ваша очередь на запись становится слишком длинной, это может привести к продолжительным открытым подключениям и в конечном итоге исчерпает ваши доступные подключения.
- Когда вы обновляете или публикуете посты, что еще происходит помимо обновления данных поста?
- Вы используете кэш-плагин, который очищает кэши, возможно, даже временные файлы в базе данных?
- Вы используете плагин XML-карты сайта, который регенерируется после публикации?
- Вы используете SEO плагин, который анализирует контент?
- Вы используете трекер ссылок или анализатор?
- Все эти вещи (или многие из них) могут способствовать потоку записей в базу данных.
Снижайте нагрузку на базу данных
Установите решение для хранения кэша объектов, если его у вас еще нет. Redis или Memcache значительно уменьшают нагрузку на вашу базу данных.
Проверьте ваши параметры
Столбец autoload в таблице параметров указывает, будут ли параметры считываться из базы данных при каждом запросе. Если это значение велико, это может привести к более длительным запросам к базе данных. Это еще одно место, где кэширование объектов может помочь. Это может не повлиять на вашу ситуацию, но стоит изучить для повышения производительности.
Ответ или решение
Проблема с превышением числа соединений в MySQL: анализ и рекомендации
Мы сталкиваемся с ситуацией, когда ваш сервер базы данных MySQL исчерпывает максимальное количество соединений, установленное на уровне 312. В условиях вашего проекта (высоконагруженный блог с 500 активными пользователями и 10,000 постов) это может вызвать серьезные проблемы с доступностью сайта, особенно во время пиковых нагрузок. Давайте подробнее разберем возможные причины и решения данной проблемы.
1. Время существования соединений
Одной из главных причин превышения числа соединений может быть длительное время существования активных соединений. Вы указали, что максимальное время выполнения скрипта составляет 5 минут (300 секунд). Это означает, что соединение может оставаться активным в течение всего этого времени, если запрос не завершается. При этом большая группа пользователей может одновременно инициировать длительные запросы к базе данных.
Решение: Рассмотрите возможность сокращения максимального времени выполнения скрипта или оптимизации запросов, чтобы они заканчивались быстрее.
2. WordPress Heartbeat API
Поскольку у вас одновременно работает до 10 редакторов, не следует забывать о механизме Heartbeat API от WordPress, который генерирует регулярные запросы к базе данных для автосохранения и обновления информации о пользователях. Каждый активный пользователь генерирует фоновые запросы, что, при высоком уровне активности, может значительно увеличивать нагрузку на базу данных.
Решение: Настройте интервал работы Heartbeat API для уменьшения его частоты или отключите его, если это возможно. Также стоит уменьшить количество версий постов, сохраняемых в базе.
3. Пиковые нагрузки во время публикации
Во время пиковых часов, когда вы или ваши блогеры публикуете посты, запросы к базе данных могут возрастать. Определенные плагины, такие как SEO или плагины для генерации карты сайта, могут вызывать дополнительные записи в базу данных всякий раз, когда происходит обновление или публикация.
Решение: Проверьте на наличие плагинов, которые могут генерировать дополнительную нагрузку на базу данных во время публикации, и оптимизируйте их использование. Также рассмотрите возможность использования кэширования, чтобы снизить нагрузку на базу данных во время пиковых часов.
4. Ресурсы сервера базы данных
Судя по описанию, ваш сервер базы данных (4 ГБ ОЗУ и 2 ядра) может быть подвержен нехватке ресурсов, особенно если происходит одновременное выполнение множества интенсивных запросов. Если RAM используется полностью, это может привести к зависаниям и завершению соединений.
Решение: Мониторьте использование ресурсов базы данных. Если RAM загружен более чем на 70-80%, рассмотрите возможность увеличения ресурсов вашего сервера или использование внешнего техподдержки для оптимизации работы.
5. Внедрение кэширования
Применение решений для кэширования, таких как Redis или Memcached, может значительно снизить нагрузку на базу данных, позволяя временно хранить часто запрашиваемые данные в памяти и улучшить время отклика.
Решение: Настройте объектное кэширование с помощью Redis или Memcached для уменьшения числа запросов к базе данных.
Заключение
Решение проблемы с превышением числа соединений в MySQL потребует комплексного подхода, включающего оптимизацию настроек веб-приложения и сервера базы данных, а также внедрение кэширования. Проведите анализ запросов к базе данных с помощью мониторинга, оптимизируйте плагины, которые используют ресурсы базы данных и перенастройте параметры соединения для достижения лучшего результата. Это позволит вашему высоконагруженному блогу функционировать более эффективно при сохранении его доступности для пользователей.