Что вызывает ошибку "max_user_connections" в WordPress на фронтенде?

19 апр. 2016 г., 01:02:24
Просмотры: 18.8K
Голосов: 3

Сейчас я получаю эту ошибку только на фронтенде (не в админке /wp-admin):

Warning: mysqli_real_connect(): (HY000/1203): User xxx already has more than
'max_user_connections' active connections in
/hermes/.../public_html/myhome/wp-includes/wp-db.php on line 1489

Warning: mysql_connect(): User xxx already has more than
'max_user_connections' active connections in
/hermes/.../public_html/myhome/wp-includes/wp-db.php on line 1515
Error establishing a database connection

И мне интересно, почему это появляется, когда я единственный посетитель? Я использую WP 4.5.

Я связался с хостингом, который любезно ответил следующее:

В настоящее время ваш сайт показывает 
'Ошибка соединения с базой данных', 
потому что пользователь базы данных 
превысил лимит одновременных подключений 
для пользователя базы данных, который составляет 10. 
Это причина, по которой сайт выдает 
ошибку базы данных. Скрипт выдает 
ошибку одновременных подключений, когда 
количество подключений к базе данных 
превышает лимит, установленный на сервере. 
На нашем shared-хостинге мы разрешаем 
максимум 10 одновременных подключений 
к базе данных, что является оптимальным 
для shared-платформы, и увеличить этот 
лимит невозможно. 

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

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

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

Другими словами, с их стороны всё в порядке, это ошибка WordPress.

7
Комментарии

У вас проблемы с хостингом. Это не совсем связано с WordPress. Вы размещаете этот сайт на своем хостинге?

prosti prosti
19 апр. 2016 г. 02:00:01

Да. Но моя админ-панель работает отлично. Пожалуйста, посмотрите ответ от хостинга выше.

Ramnath Ramnath
19 апр. 2016 г. 02:18:07

@prosti Нет, это не проблема хостинга. Проблема, похоже, в теме или плагине. 10 одновременных подключений более чем достаточно для большинства случаев использования на небольших сайтах.

kaiser kaiser
19 апр. 2016 г. 02:52:54

@kaiser Странно, но проблема иногда полностью исчезает. Можешь подсказать, как мне провести диагностику, не экспериментируя наугад? Я уже потратил много времени. Спасибо!

Ramnath Ramnath
19 апр. 2016 г. 03:17:57

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

kaiser kaiser
19 апр. 2016 г. 03:20:22

@kaiser Пробовал debug bar. Но это не помогло, так как проблема возникает, когда сайт не соединяется. Также я выяснил, что это проблема темы. Когда я меняю тему на Twenty Fifteen, всё работает гладко! Вопрос: как мне исследовать и применить правильные исправления? Спасибо.

Ramnath Ramnath
19 апр. 2016 г. 23:29:03

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

kaiser kaiser
19 апр. 2016 г. 23:33:35
Показать остальные 2 комментариев
Все ответы на вопрос 3
3

Не связано с WordPress, поэтому я не уверен, имею ли я право отвечать здесь, но все же увеличьте параметр max_user_connections в файле конфигурации MySQL my.cnf, так как вы просто тестируете.

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

Решение: Некоторые люди увеличивают max_connections до очень высокого значения, чтобы MySQL никогда не исчерпывал соединения.

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

19 апр. 2016 г. 02:05:20
Комментарии

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

Ramnath Ramnath
19 апр. 2016 г. 02:19:33

У вас может быть mysql_connect() без закрытия соединения. Кстати, это плохая практика в WordPress. Подумайте.

prosti prosti
19 апр. 2016 г. 02:23:01

Но я недавно просто обновил WP до версии 4.5. Что мне теперь делать?

Ramnath Ramnath
19 апр. 2016 г. 02:38:02
4

Сначала необходимо включить отображение ошибок для $wpdb, абстракции базы данных WordPress:

$GLOBALS['wpdb']->show_errors;

Иначе ни одно из подключений к базе данных не завершится с ошибкой и не вернёт экземпляр \WP_Error. По умолчанию код ошибки — 500.

Следующая ошибка исходит из метода \wpdb::db_connect():

Ошибка при подключении к базе данных

Метод db_connect() используется в двух случаях:

  1. Подключение к базе данных
  2. Проверка наличия соединения с базой данных

Только первый вариант может завершиться с ошибкой. Если соединение прервётся во время проверки, оно не завершится с ошибкой и не вызовет эту ошибку. Само подключение осуществляется методом \wpdb_driver::connect(), который проверяет, активно ли соединение и доступно ли оно. Это говорит о том, что ваша проблема связана именно с подключением. Вы можете посмотреть это (без шуток) в следующем файле:

# interface-wp-driver.php
<?php
abstract class wpdb_driver {

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

Перед тем как соединение будет объявлено "неудачным" и ошибка будет выведена, есть одна интересная строка:

require_once WP_CONTENT_DIR . '/db-error.php';

Это означает, что перед тем как всё "упадёт", загружается Drop In. Вы можете использовать это для запуска механизма отладки. В этом файле доступно всё ядро WordPress. Вы можете начать отправлять себе письма, логировать ошибки в ELK/Kibana, Spark или любой другой стек, SaaS или даже в Slack (или просто в текстовый файл). Логируйте ошибки, анализируйте происходящее, сохраняйте маршруты, запросы, данные подключения к базе данных — всё, что может вам помочь.

20 апр. 2016 г. 00:40:44
Комментарии

На самом деле это была ошибка темы. После провала всех тестов я попросил создателя темы проверить, он исправил и признал ошибку. Спасибо.

Ramnath Ramnath
2 мая 2016 г. 18:11:17

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

kaiser kaiser
2 мая 2016 г. 22:25:06

Меня попросили отправить данные для входа, и после этого я не уверен, что именно сделал автор, но да, возможно, он применил некоторые исправления. Все, что я знаю - тема была обновлена. Поэтому я бы посоветовал другим, столкнувшимся с подобными проблемами, обновить ядро WP и также тему до последних версий. Спасибо.

Ramnath Ramnath
2 мая 2016 г. 22:46:23

@Ramnath Извините, но это не решение. Вы перенесли проблему сюда, пожалуйста, попросите автора либо ответить здесь, либо запросите у него исправления. Вам самому нужно понимать это на случай, если придется восстанавливать сайт после взлома, из-за сбоя хостинга или других обстоятельств.

kaiser kaiser
3 мая 2016 г. 01:54:16
1

Веб-серверы могут обрабатывать множество задач одновременно... При условии, что ваша тема не пытается обращаться к базе данных напрямую (не через класс WPDB), каждое пользовательское соединение должно соответствовать времени обработки запроса, с которым работает WordPress.

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

(это, по сути, то, что вам сказал хостинг, и это имеет смысл)

20 апр. 2016 г. 00:53:38
Комментарии

Однажды у меня была подобная ситуация, и я был уверен, что хостинг-провайдер напортачил или сайт взломали. Оказалось, что был запрос, выполнение которого занимало примерно в 6 раз больше времени с каждым добавленным условием, что очень быстро увеличивало общее время выполнения. Как только достаточное количество пользователей начало выполнять этот запрос — всё, операция не завершалась, и соединения с базой данных не закрывались. Я бы рекомендовал проверить, нет ли у вас похожих скриптов, а также установить плагин Query Monitor и проанализировать фронтенд и бэкенд на наличие медленных запросов.

Joel M Joel M
15 февр. 2018 г. 08:58:26