Почему падает MySQL (mysqld_safe mysqld restarted) без других логов и как исправить?

Question

[inpost]

Здравствуйте.
Временами в логам появляются ошибки:
SELECT * FROM `gift` WHERE `man_id` = 173232
150419 19:02:34 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statements writing to a table with an auto-increment column after selecting from another table are unsafe because the order in which rows are retrieved determines what (if any) rows will be written. This order cannot be predicted and may differ on master and the slave. Statement: INSERT INTO `requests_bu`
SELECT * FROM `requests` WHERE `id_man` = 173232

Эту проблему можно исправить, собственно, мелочь же. Основная причина - падение мускула с ошибкой. Падения происходят с интервалом от 12 часов до 48 часов.
Бывает, что прошлых логов уже как час-два нет, но всё равно неожиданно рестартит:
mysqld_safe mysqld restarted

Общие показатели работоспособности сервера хорошие, лишние ресурсы имеются. Запросы работают быстро, сайт не тормозит, всё устраивает. Как найти причину, почему неожиданно он перезагружаться стал? Наугад выделять дополнительные ресурсы тоже не хочется, сами понимаете. Прошлая попытка увеличить кеш InnoDB привёл к тому, что мускул стал рестартиться каждые 6 часов.
Вот так выглядит База Данных:

Answer 1

[Евгений]

Как минимум, посмотрите ещё системные логи ОС - нет ли там информации об отключениях MySQL или его "убийства" со стороны OOM-киллера.
Так же можно поставить atop на сервер и логировать происходящие на сервере процессы. В момент падения MySQL посмотреть ситуацию на сервере (нагрузка, потребление ОЗУ, количество процессов всех сервисов).

Прошлая попытка увеличить кеш InnoDB привёл к тому, что мускул стал рестартиться каждые 6 часов.

Вот этот момент очень напоминает работу OOM-киллера.

Answer 2

[inpost]

Я думал, что Мускулу не хватало памяти. Было 30GB, докупил памяти до 96GB на сервер с 48, на мускул выделил 64GB, но спустя 2-е суток снова упало всё. То есть до какого-то момента всего хватало, а потом наступил час Х и стал падать. Память в какой-то момент скакнула мускула и снова Киллер его убил. Может не так настроил? Помогите, пожалуйста с ситуацией. Или скажите что делать, чтобы этого больше не повторилось?
Вот настройка конфига:

[mysqld]
memlock
max_allowed_packet=128M
#skip-networking
low-priority-updates
skip-external-locking
key_buffer = 512M
table_cache = 32768
thread_cache_size=4
interactive_timeout=360
wait_timeout=120
max_connections=250
thread_concurrency=6
query_cache_limit=4G
query_cache_size=4G
myisam-recover=BACKUP,FORCE
tmp_table_size=14G
tmpdir=/tmp1
max_heap_table_size=14G
local-infile=0
concurrent_insert=2
innodb_flush_method=O_DIRECT
skip-innodb_doublewrite
innodb_thread_concurrency=100
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT

innodb_log_file_size=512M
innodb_buffer_pool_size=64G
innodb_use_sys_malloc = 0
innodb_log_buffer_size=32M
#innodb_data_file_path=ibdata1:10M:autoextend
#innodb_file_per_table=1
#log-slow-queries=/var/log/slow-query.log
log-queries-not-using-indexes
#long_query_time = 3
skip-name-resolve
log-bin=mysql-bin
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1
sql-mode=

Comments

[Евгений]

Тут нужно смотреть состояние сервера во время падения. Кто наибольший потребитель памяти(возможно что это и не MySQL) ? Чьих процессов в системе больше всего и почему так произошло?

На эти вопросы поможет ответить atop или подключение системы мониторинга к серверу(мы обычно используем Zabbix).

Для чего используется сервер? Если это веб-сервер - надо смотреть нагрузку которую создают Apache или PHP-FPM, uwsgi или какие-либо другие backend-сервера(смотря что у Вас используется для этого). Веб-сервера тоже любят память.. особенно много памяти если их ничего не сдерживает :)