stump
Этот лог за несколько минут даёт 100-150мб. Что за советы?
И как мне это поможет? Ты считаешь, что запрос без ошибок, который выполняется КАЖДУЮ 1 минуту неожиданно дал ошибку, которая не залогировалась? И что я тогда увижу? Какой смысл видеть самый последний запрос к БД? К тому же происходит следующее, начинает резко переполняться очередь, как бы ресурсы улетают в никуда и Мускул работает ещё 1 минуту до падения, но там видно, что абсолютно вся система не справляется, как бы до упора дошли.

Ищём проблему с админом... зачем писать в теме, если не знаешь по ней ничего? Не понимаю. Если тебе хочется накрутить сообщения, то напиши FatCat, попроси, чтобы "Сообщения" накрутил, может можно прибавить пару тысяч.

T1grOK
Ты говоришь о мониторинге операционной системы? Я не увидел там мониторинг внутри MySQL. То есть потребление самим мускулом не изменяется, проверяем через мунин. Нет скачка по нагрузке и на сервере остаются лишние ресурсы, при этом сам же мускул резервирует внутри у себя часть памяти, если я правильно понимаю систему работу MySQL. Проблема же в том, что внутри по какой-то причине он падает, может быть что-то вызывает ошибку, или же заканчивается внутренний лимит резерва, но чего именно?! Наугад админ попробовал увеличить несколько параметров с ИнноDB, в ответ мускул за сутки 3 раза упал, сделали откат назад.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

inpost, что в параметре max_allowed_packet? Присутствуют ли где-нибудь поля типа BLOB/LONGBLOB?

paul85
~100M. BLOB/LONGBLOB не используется.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

paul85
Кажется ошибка вылетать должна, а не просто так рестартиться в случае превышения пакетов. Может быть наоборот, просто большой пакет загоняю в MySQL и стоит эти лимиты уменьшить?

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

inpost, я бы увеличил до 500Мб. Посмотрел бы что получится. Раз картина по логам неясная...

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

_____________
Трус не играет в хокей

inpost использование INNODB необходимо в проекте ? ... если нет попробуй сделать дубликат таблицы на MyIsam и погонять на нем, помониторить ..

_____________
Прогноз на следующие 5 лет : Россия, Китай - две величайшие державы.
США в Ж*пе. Справедливость восторжествует. )

andrey888
Ты, наверное, шутишь. Да? На высоконагруженном проекте отказываться от InnoDB без причины. Пусть все селекты начнут работать медленнее, просто так захотелось и никто в мире не использует InnoDB?

S.Chushkin
5.5 . Админ обещал сегодня обновить до последней 5.6.

T1grOK
Спасибо, гляну

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

inpost
Нет не шучу )..

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

_____________
Прогноз на следующие 5 лет : Россия, Китай - две величайшие державы.
США в Ж*пе. Справедливость восторжествует. )

Ладно. всем спасибо. Причину подсказали на других форумах.


Админ не увидел логи сервера, очень странно, ведь я ему говорил где искать. Когда сам начал копать все логи выяснилось, что Мускул убивает Killer, отсюда логи мускула пустые.
При падении и при подъеме мускула можно было увидеть, как простой запрос по индексам к двум первым таблицам (общим объемом более 30гигов) выполнялся очень медленно, хотя EXPLAIN чётко показывал, что запросы идут по индексам. Запрос был следующего плана

SELECT COUNT(*)
FROM `dat_mess_sett`
LEFT JOIN `dat_mess` ...
...

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

stump
Тебе особое спасибо. Всё же был не прав, мозговой штурм тут нужен, когда проблема не очевидна.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

paul85
У нас так не принято

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).