Как отследить момент падения MySQL

http://ping-admin.ru/

Ping-Admin.Ru осуществляет круглосуточный мониторинг доступности и проверку работы на сервере таких сервисов как:

HTTP, HTTPS (проверка работоспособности сайта).

FTP.

MySQL, PostgreSQL (проверка работоспособности базы данных).

POP3, SMTP, IMAP (проверка работоспособности почты).

DNS.

Ping.

Telnet.

надо искать причину падения, а не костыли городить.

в логах ничего нет? :)

на чём mysql крутится (дедик или впска)?

Скорей всего сама ОС рестарт делает при крашах. Посмотрите системные логи (/var/log/syslog - если deb-based система или /var/log/messages - если rpm-based - centos). Хотя, в centos такой штуки насколько я знаю, нету. А вот в ubuntu вполне может быть. Там в /etc/init/mysql.conf есть настройки respawn - это вот оно. Какая ОС?

В общем, читайте логи. Системные и самой СУБД ( /var/log/mysql* ) Там всё написано - кто или что, когда и почему упало или было перезагружено. Ещё можете выключить mysql и запустить его не сервисом, а просто из консоли - mysqld & . В этом случае оно при падении скорей всего так и останется лежать.

А там, наверное, нет краша.

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

Надо уточнить.

Сервер centos Nginx, 25гб памяти.

долго скрипты обрабатывает, выдает ошибку 500 периодически и

Database Error: Unable to connect to the database:Could not connect to MySQL

В PHP.INI прописано:

max_execution_time = 180 ;

max_input_time = 60 ;

max_input_nesting_level = 64 ;

memory_limit = 512M ;

proxy_send_timeout 60;

proxy_read_timeout 60;

Возможно необходимо Nginx настроить?

Это надо смотреть. Может nginx, а может что-то ещё. 25гб - наверное не памяти, а диска? Сообщение лишь о том, что php не может подключиться к mysql. А почему не может - это нужно смотреть логи самого mysql. Сначала нужно выяснять именно это. Nginx здесь вряд ли, если и может быть "виноватым", то в самую последнюю очередь.

Скрипты долго грузятся.

25 гб памяти, но винт медленный.

Почти каждый день бывает выдает ошибку 500, на некоторых сайтах ошибку базы.

Сейчас вроде все нормально:)

Поставьте лучше munin и смотрите на графики в момент падения MySQL.

munin стоит, но ничего не вижу:( нету перегрузок ЦПУ и винта.

Спустя 4 дня мускул вновь упал по неизвестной причине. Пришлось перезагружать.

Оттюнил nginx.

Прописано:

worker_processes 8;

worker_rlimit_nofile 16384;

worker_connections 2048;

Какой оптимальный worker_connections ? Может worker_rlimit_nofile и worker_connections увеличить в 1,5 раза?

Выдает неправильный синтаксис:

error_log /dev/null crit;

multi_accept on;