Не совсем понятно, почему перестает работать связка MySQL+apache+PHP. До какого то времени все работало без сбоев, но последнее несколько дней начались глюки... периодически отрубается MySQL т.е. коннект к базе не проходит после перезагрузки все нормально работает (несколько часов). Подскажите как выяснить причину "падения" MySQL. Нехватка памяти при "бешеных" запросах к базе или другие "глюки". Спасибо.

vkleChek_FedorНехватка памяти при "бешеных" запросах к базеПочему Вы считаете что такое событие имеет место быть?
Изменилось только то, что наступило время отчетов. Пользователи с помощью ВЕБ-интерфейса "делают" выборку. Возможно что пытаются выгрузить данные за целый год или еще что похлеще одним "махом". Если честно я не совсем в курсах как работает MySQL во время "select * from table" куда происходит эта выборка? В физическую память или виртуальную на жесткий диск или...? И самое главное где и в каких логах посмотреть причину отказа. Что накрылось служба apache или MySQL и из-за чего. Хотя нужно было не reboot'ить сервак, а попробовать поочередно перезапустить эти службы (таким образом выяснив, хотя-бы частично, что не работало).

vkleТакие запросы не должны проходить бесследно. Включите лог медленных запросов в my.cnf.
Т.е. это может быть причиной отказа?


vkleДык мониторить то можно много чем. Хотите - свой скрипт напишите, хотите готовое юзайте. Тот же monit, например.
Дык это... основных логов то с гулькин нос. Если только процесс в кору не ушел, конечно

Дык сисадмин болеет, а я только учусь... "Оконный" я последний раз общался с SUSE 10.x лет 5-7 назад.

vkleВот за "*" аффтарам запроса можно отрывать известно чего. Что касается "куда идет". Во-первых - в память. Возможно, в кеш запросов. Во-вторых - ответ так или иначе должен попасть отправителю. В Вашем случае это PHP, скорее всего. Таким образом, опять таки, память.
"*" Это всего лишь пример на самом деле там все "путем".

vkleОднако, на вопрос "Почему Вы считаете что такое событие имеет место быть?" относительно Вашего предположения о нехватке памяти Вы так и не дали ответа. Несмотря на то, что процитировали и то и другое.
Навели на мысль другие, и я сегодня узнал сколько там памяти... 1 Гиг
sar - смотрели за проблемный период?

Где искать, как смотреть дабы не навредить системе. (посмотреть то я конечно посмотрю если найду). Спасибо

vkle,
Спасибо, к сожалению добраться до сервака смогу только после выходных. Если одна "штука" в голову не стукнет и я завтра не соберусь на работу сходить (хотя охрана не пропустит:). Юзается он прилично... Как определить забит ли своп ведь после падения MySQL своп наверное очистится, или мониторить его во время работы. Еще раз спасибо, хоть немного заполнили мои пробелы (ну нет у меня пока желания углубляться в FREEBSD)

vkle,
Я бы с удовольствием но начальство... не оценит еще и за самоуправство люлей навешает. monit это утилита стандартная или... ее ставить нужно если стандарт то как пользоваться можно ссылкой в гугл

vkleChek_Fedormonit это утилита стандартная или... ее ставить нужноНужно ставить. Ссылка... Ну попробуйте начать со слова "monit"

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


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

Еще вопросик такой "частый" раз в 2-4 часа не повредит всей системе, т.е. эта строка может послужить гильотиной для моей головы :) Круть я на седьмом небе счастья столько нового узнал

vkleChek_FedorЕще вопросик такой "частый" раз в 2-4 часа не повредит всей системе, т.е. эта строка может послужить гильотиной для моей головы :)Может и послужить. Системе то оно не повредит, а вот данные, те что в базе... В общем, могут быть какие-то потери, если крах происходит во время записи.
Так если MySQL уже не работает о каких данных может быть речь они будут потеряны уже в тот момент когда MySQL отрубится.

VGrey* * * * * if ! /usr/bin/pgrep mysqld ; then /usr/local/etc/rc.d/mysql-server restart ; fi >/dev/null
Прописал в crontab строку только я фик ее знает работает она или нет. Я в синтаксисе не уверен пробел между ! /usr обязателен и mysqld[пробел];

Вот блин "/usr/bin/pgrep mysqld" выводит PID процесса но в моем случае когда MySQL перестает работать /usr/bin/pgrep mysqld возвращает значение отличное от null (вернул 654) соответственно проверка if !... "говорит" что все нормально. Есть способ проверить работоспособность MySQL чтобы в нужный момент перезапустить его? Спасибо.

vkleChek_Fedor"/usr/bin/pgrep mysqld" выводит PID процесса но в моем случае когда MySQL перестает работать /usr/bin/pgrep mysqld возвращает значение отличное от null (вернул 654)Интересно, интересно. Процесс жив, а мускуль "не работает"? Может быть мускуль и не падает вовсе, а что-то другое происходит? Например, пользователь впирается в ограничение на число коннектов за час. Самому интересно, что за причина, но рестарт помогает.

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