Ресурс Mysql временно недоступен

Ответ 1

Я все еще не нашел, какие ограничения он наносил, но мне удалось обойти эту проблему. Возникла проблема с нашей таблицей сеансов (в vbulletin), которая использует движок MEMORY. Индексами для этой таблицы были HASH, и, таким образом, когда vbulletin очищал эту таблицу один раз в час, он блокировал бы таблицу достаточно долго, чтобы задержать другие запросы, и превзойти mysql до предела своих ресурсов.

Изменяя индексы на BTREE, это позволило MySQL быстрее удалять строки из таблицы сеансов и избегать любых ограничений, которые были достигнуты ранее. Ошибки начались только тогда, когда мы обновили наш сервер master db до MySQL 5.5, поэтому я предполагаю, что таблицы MEMORY обрабатываются по-разному в последней версии.

См. http://www.mysqlperformanceblog.com/2008/02/01/performance-gotcha-of-mysql-memory-tables/ для получения информации о скорости увеличения с использованием индексов BTREE над HASH для MEMORY.

Ответ 2

Предположим, что ваша система в настоящее время основана на Unix (как указано в вашей постановке проблемы). Если это правильно, вот набор проблем, с которыми вы можете столкнуться:

• Вы исчерпали memory, доступный для MySQL.

  Это наиболее вероятная проблема, с которой вы столкнулись. Для каждого соединения в пуле соединений MySQL требуется, чтобы память функционировала, и если этот ресурс исчерпан, дальнейшие соединения не могут быть сделаны. Разумеется, следы памяти и максимальные размеры пакетов различных операций могут быть настроены в ваш эквивалент my.cnf, если вы обнаружите, что это проблема.

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

• Вы исчерпали файловые дескрипторы, доступные вашей учетной записи пользователя MySQL.

  Еще одна распространенная проблема: если вы пытаетесь обслуживать запросы, требующие файла IO выше границы 1024 (по умолчанию), вы столкнетесь с ситуациями, когда операция просто терпит неудачу. Это связано с тем, что в большинстве систем определяется мягкое и жесткое ограничение количества дескрипторов открытых файлов, которые каждый пользователь может иметь в наличии, и прохождение этого порога может вызвать проблемы.

  Это обычно будет иметь ряд очевидных признаков, выраженных в ваших файлах журналов. Проверьте /var/log/messages и сопоставимые каталоги (например, /var/log/mysql, чтобы узнать, можете ли вы найти что-нибудь интересное.

• Вы столкнулись с сценарием livelock или deadlock, где ваш поток неудовлетворен.

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

• В вашей системе заканчиваются PID, доступные fork.

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

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

• Прокси-сервер или диспетчер соединений вверх по потоку исчерпали ресурсы и прекратили запросы на обслуживание.

  Если у вас есть уровень обслуживания между вашим клиентом и MySQL, он проверяет, не разбился ли он, не повесился или не стал неустойчивым. Приведенный выше совет.

• Ваш портмодер исчерпал себя после 65 536 соединений.

  Вряд ли, но опять же, возможный случай истощения. Проверка тривиального сервисного соединения, как указано выше, - ehm, также лучший порт захода здесь.

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

Ответ 3

Боже, это может быть так много. Может случиться так, что пространство буфера сокета исчерпано. Возможно, что mysql не принимает соединения так быстро, как они поступают, и достигнут предел отставания (хотя я ожидаю, что вы получите сообщение об ошибке "Отказано в соединении", я точно не знаю, что вы получите для сокета домена Unix). Это может быть любая из вещей, на которые указывает @MrGomez.

Поскольку вы используете Apache и MySQL на одном сервере, и это проблема при высокой нагрузке, вполне возможно, что Apache голодает из системы какого-либо ресурса, и вы просто не видите (замечаете?) сброшенный/не удалось выполнить входящие соединения/запросы в ваших журналах.

Используете ли вы пул соединений? Если нет, я бы начал там.

Я также искал бы ошибки в журналах и syslog Apache примерно в то же время, что и ошибка mysql_connect, и посмотрю, что еще может получиться. Я бы рекомендовал, чтобы MySQL перешел на отдельный выделенный выделенный сервер.

Ответ 4

В моем случае я работал с типами данных JSON с помощью PDO (PHP Driver). Я использовал fetch для получения одного элемента, но забыл добавить LIMIT 1 в запрос. Добавление его решило проблему.