Падает MySQL при большом кол-ве запросов. Что можно сделать?

Такая ситуация, очень живой сайт (интерент издание), иногда бывает множесто одновеременных обращений к MySQL, из-за чего мускул в такие пики иногда падает с ошибкой: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (11)

Что посоветуете? Варианты и причины ошибки? Добавил в my.cnf строку: set-variable=max_connections=500

Не помогает, кто работал с большими загруженными серваками, подскажите?

Ссылка

← Трабл с Mplayer в fc 5

Ошибка startkde →

Маловато инфы.

Такая ошибка получится в самых разных ситуациях: 1) Превышен лимит на кол-во одновременных соединений к серверу от конкретного юзверя 2) Аналогично, но заняты все соединения с сервером. Общий лимит. 3) Сам сервер отвалился.

В зависимости от... нужны самые различные меры по решению проблемы.

Valmont ★★★
(24.08.06 00:20:24 MSK)

Ответ на: комментарий от Valmont 24.08.06 00:20:24 MSK

1. У множества разных пользователей с разными IP одна и также ошибка в период "дауна" таким вот сообщеним. Не только у одного! 2. Сервер не отваливается, Веб-сервер, мыло, ssh и т.п. работает, но с большими тормозами.

Какую доп.инфу еще надо?

anonymous
(24.08.06 00:25:59 MSK)

Было такое же (правда на 3 и 4 версиях) ... просто перешли на постгрес. Он нормально держит на порядок больше соединений и работает под нагрузкой на порядок быстрее. мускуль это для совсем маленьких нагрузок.

vtVitus ★★★★★
(24.08.06 14:26:48 MSK)

Ссылка

Ответ на: комментарий от anonymous 24.08.06 00:25:59 MSK

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

Возможно перекомпилить mysql под эту машину с оптимизирующими флагами, выкинуть лишнее и т.д.

Плюс. Я бы поработал над логами, посмотреть, какой из аккаунтов особенно нагружает сервер. Дело в том, что в самом мускле не предусмотрена защита от одного злого пользователя, чтоб не страдали другие, то есть нету нормлаьного лимитирования. И уже решать проблему немного с другой стороны - перерабатывать проблемные скрипты, либо пинать пользователя, которому они пренадлежат, чтобы он это сделал. Оптимизировать сами таблицы (начиная с check&repair, так как иногда сбойные таблицы сами служат причинами падения демона и заканчивая настройкой индексов, но там индивидуально, так как, еслия не ошибаюсь, оптимизатор там хреновый. так говорят :) )

Если Все варианты не катят, то вынести сервер бд на отдельную машину.

Valmont ★★★
(24.08.06 14:40:23 MSK)