Приветствую ув. сообщество форума.

На вас последняя надежда. :) MySQL работает очень странным образом. Уводит сервер в даун на ровном месте.

У меня VDS. Установил на нее Debian7 (голую), затем установил VestaCP, которая подтянула за собой Мускул, веб-сервера и прочее.

Восстановил из бэкапа сайты. Все заработало. На сайты ходят люди, боты, в общем все хорошо.

Через пару часов открываю htop вижу LA > 30. Смотрю access логи мускула и nginx, запросы идут, но не много, явно не столько чтобы положить сервер.

Отключаю nginx. И тут внимание - нагрузка никуда не пропадает. Mysql продолжает жрать проц и давать огромный LA.

Снова смотрю access логи - запросов нет. К MySQL не идет не единого запроса, а он каким-то образом еще долго продолжает жрать проц и тормозить систему.

Прилагаю скрин с htop. На момент скрина веб-сервер уже пару минут выключен.

Кроме сайтов у меня нет каких-либо приложений, которые обращаются к MySQL. Да и access лог пуст. Так что даже не знаю, что тут думать.

Вывод команды mysqladmin proc. Уже становится немного понятнее. =)

Эти висячие запросы по идее должны отрабатывать моментально.

А почему же они висят в этом статусе "Sending data"?

miksoftПодозреваю, что переносе базы было что-то забыто, например, какой-нибудь индекс. Или какие-то настройки, даже, может быть, с кодировкой.


Дело в том, что до переноса уже была эта проблема. Собственно поэтому и решил перенести. (

WMDmitry, запустите консоль mysql и посмотрите командой SHOW FULL PROCESSLIST какие запросы выполняются в данный момент. Или можно Slow Log настроить, чтобы видеть долгоиграющие запросы.

SHOW FULL PROCESSLIST - выдает то же что и mysqladmin proc.

Думаю Slow Log уже можно не настраивать. :) Понятно, что туда выпадут все эти запросы, которые висят в SHOW FULL PROCESSLIST.

miksoftWMDmitry,

Если версия MySQL ниже 5.6, то избавляйтесь от конструкции IN (SELECT ...), т.к. оптимизатор будет выполнять подзапрос столько раз, сколько будет нужно проверить результат этого выражения. В результате чего время выполнения запроса вырастает многократно.

SQL_CALC_FOUND_ROWS тоже далеко не бесплатная фича, не стоит ее употреблять без осознанной необходимости.

Понял Вас, спасибо. На данный момент по крайне мере удалось обнаружить проблему. Будем работать над ее устранением. :)

Версия сервера - 5.5.46-0

MasterZivты че же настрой...
Ок, настрою. :)

авторА не может быть так, что в ЭТОМ инсталляторе косячок какой затесался?

Да нет вроде, теперь знаю, моя проблема во всяком случае не в этом. :)