SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 04.12.2016 09:27:40

mmx
Участник
Зарегистрирован: 23.05.2013
Сообщений: 11

Неизвестная причина падения mysql

Приветствую.

Периодически падает mysql по ночам, подозреваю что ложит задание резервного копирования бд на 400мб средствами ispmanager, но странно, что раньше до обновления mysql не было такой проблемы, переехал с mysql на mariadb. 90% таблиц в Aria, select в общей выборке по запросам составляет 95%. Машина centos 6.8 с 8 ядрами и 32 гб оперативки. по top mysql иногда временами сильно нагружает процессор до 200%. Прошу помочь определить причину падения и нагрузок, также прошу помочь с настройками в server.cnf. Заранее благодарю.

Лог mariadb:

Код:

2016-12-04  0:22:13 140634128295680 [Note] /usr/sbin/mysqld: Normal shutdown

2016-12-04  0:22:20 140634128295680 [Note] Event Scheduler: Purging the queue. 0 events
2016-12-04  0:22:23 140636327995136 [Note] InnoDB: FTS optimize thread exiting.
2016-12-04  0:22:23 140634128295680 [Note] InnoDB: Starting shutdown...
2016-12-04  0:22:23 140634128295680 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
2016-12-04  0:22:25 140634128295680 [Note] InnoDB: Shutdown completed; log sequence number 225270740748
2016-12-04  0:22:25 140634128295680 [Note] /usr/sbin/mysqld: Shutdown complete

161204 00:22:25 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
161204 00:22:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2016-12-04  0:22:25 140527399499808 [Note] /usr/sbin/mysqld (mysqld 10.1.19-MariaDB) starting as process 6081 ...
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: The InnoDB memory heap is disabled
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Using Linux native AIO
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Using SSE crc32 instructions
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Initializing buffer pool, size = 4.0G
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Completed initialization of buffer pool
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Highest supported file format is Barracuda.
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: 128 rollback segment(s) are active.
2016-12-04  0:22:26 140527399499808 [Note] InnoDB: Waiting for purge to start
2016-12-04  0:22:26 140527399499808 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.32-79.0 started; log sequence number 225270740748
2016-12-04  0:22:26 140520871397120 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-12-04  0:22:26 140527399499808 [Note] Plugin 'FEEDBACK' is disabled.
2016-12-04  0:22:26 140527399499808 [Warning] 'user' entry 'root@server' ignored in --skip-name-resolve mode.
2016-12-04  0:22:26 140527399499808 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.19-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 0  MariaDB Server

Конфиг mariabd (server.snf):

Код:

# this is read by the standalone daemon and embedded servers
[server]

# this is only for the mysqld standalone daemon
[mysqld]
skip-name-resolve
skip-networking
low-priority-updates
key_buffer_size = 512M
max_allowed_packet = 8M
table_open_cache = 100000
sort_buffer_size = 64M
read_buffer_size = 64M
join_buffer_size = 384M
read_rnd_buffer_size = 32M
net_buffer_length = 2K
thread_stack = 128K
max_connections=5000
query_cache_size = 128M
query_cache_limit = 2M
tmp_table_size = 512M
max_heap_table_size = 512M
thread_cache_size = 64
ft_min_word_len=3
#wait_timeout = 600
#interactive_timeout = 120
innodb_buffer_pool_size = 4G
innodb_log_buffer_size = 512M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 5
#Slow Query Log
slow_query_log = 1
long_query_time = 3
slow_query_log_file = /var/log/mysql_slow.log
log_slow_verbosity = query_plan
#log_queries_not_using_indexes

#
# * Galera-related settings
#
[galera]
# Mandatory settings
#wsrep_on=ON
#wsrep_provider=
#wsrep_cluster_address=
#binlog_format=row
#default_storage_engine=InnoDB
#innodb_autoinc_lock_mode=2
#
# Allow server to accept connections on all interfaces.
#
#bind-address=0.0.0.0
#
# Optional setting
#wsrep_slave_threads=1
#innodb_flush_log_at_trx_commit=0

# this is only for embedded server
[embedded]

# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]

# This group is only read by MariaDB-10.1 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand
[mariadb-10.1]

Лог monit:

Код:

[MSK Dec  4 00:22:06] error    : 'mysqld' failed protocol test [MYSQL] at /var/lib/mysql/mysql.sock -- Error receiving server response -- Resource temporarily unavailable
[MSK Dec  4 00:22:12] info     : 'mysqld' trying to restart
[MSK Dec  4 00:22:12] info     : 'mysqld' stop: /etc/init.d/mysql
[MSK Dec  4 00:22:25] info     : 'mysqld' start: /etc/init.d/mysql
[MSK Dec  4 00:23:26] info     : 'mysqld' connection succeeded to /var/lib/mysql/mysql.sock

Неактивен

 

#2 06.12.2016 13:58:38

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Неизвестная причина падения mysql

В логе MySQL интересно то, что было до тех строк, которые Вы написали. Иначе тут видно, что monit перезапустил MySQL, ну и он корректно перезапустился. Может быть багой monit, может быть какой-то другой багой. Было бы здорово посмотреть, в чем проблема, и не давать monit перезапускать. Без диагностики понять, что не так, — сложно.

Неактивен

 

#3 06.12.2016 14:28:46

mmx
Участник
Зарегистрирован: 23.05.2013
Сообщений: 11

Re: Неизвестная причина падения mysql

paulus написал:

В логе MySQL интересно то, что было до тех строк, которые Вы написали. Иначе тут видно, что monit перезапустил MySQL, ну и он корректно перезапустился. Может быть багой monit, может быть какой-то другой багой. Было бы здорово посмотреть, в чем проблема, и не давать monit перезапускать. Без диагностики понять, что не так, — сложно.

Такое ощущение, что ложит задание резервного копирования, ложит то mysql, то php-fpm. Когда отключаю задание резервного копирования - все нормально, но не понятно почему, то ли задание ложит, то ли скрипт задания ispmanager. Думаю, как вариант отключить панель ispmgr и запустить какой нибудь отдельный скрипт резервного копирования. А по поводу до тех строк, до тех строк начинается лог предыдущего дня, например:

Код:

2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : Completed
2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : Start merge-sorting index `id` (2 / 2), estimated cost : 11.1111
2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : End of  merge-sorting index `id` (2 / 2)
2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : Start building index `id` (2 / 2), estimated cost : 16.6667
2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : End of building index `id` (2 / 2)
2016-12-03 16:23:22 140636306585344 [Note] InnoDB: Online DDL : Completed

Отредактированно mmx (06.12.2016 14:38:40)

Неактивен

 

#4 06.12.2016 14:41:41

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Неизвестная причина падения mysql

Ну то есть в логе MySQL никаких проблем не видно. Это хорошо. Давайте разбираться с монитом — как у него организована проверка? Может быть так, что там какой-то очень небольшой таймаут, а во время бэкапа база нагружена, и не успевает ответить за этот таймаут?

Неактивен

 

#5 06.12.2016 14:58:10

mmx
Участник
Зарегистрирован: 23.05.2013
Сообщений: 11

Re: Неизвестная причина падения mysql

paulus написал:

Ну то есть в логе MySQL никаких проблем не видно. Это хорошо. Давайте разбираться с монитом — как у него организована проверка? Может быть так, что там какой-то очень небольшой таймаут, а во время бэкапа база нагружена, и не успевает ответить за этот таймаут?

if failed unixsocket /var/lib/mysql/mysql.sock protocol MYSQL then restart
Когда делаю бекап через mysqldump - проблем не возникает

Отредактированно mmx (06.12.2016 15:00:17)

Неактивен

 

#6 08.12.2016 21:48:05

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Неизвестная причина падения mysql

Если всё так, то MySQL перестает слушать mysql.sock. Это так? Можете какой-то другой утилитой проверить?

Неактивен

 

#7 13.12.2016 08:54:10

mmx
Участник
Зарегистрирован: 23.05.2013
Сообщений: 11

Re: Неизвестная причина падения mysql

Сегодня такое в логе обнаружил:

Код:

161213  0:27:21 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 10.1.19-MariaDB
key_buffer_size=536870912
read_buffer_size=67108864
max_used_connections=1044
max_threads=5002
thread_count=960
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 656249147 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x7f86f32c0008
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f87c25bbd40 thread_stack 0x20000
161213 00:27:22 mysqld_safe Number of processes running now: 0
161213 00:27:22 mysqld_safe mysqld restarted

Неактивен

 

#8 13.12.2016 11:46:39

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6756

Re: Неизвестная причина падения mysql

Вот в этом месте он точно убился. 960 подключенных соединений. Никто не смотрит, сколько, собственно, из них работали? Было бы здорово на это посмотреть. И убедитесь, что все выделения памяти осмысленно стоят. Вряд ли у Вас на сервере 650 гигабайт ОЗУ.

Кстати, если это действительно нехватка памяти и пришел ООМ, то про это должна быть запись в dmesg сервера.

Неактивен

 

#9 13.12.2016 12:45:51

mmx
Участник
Зарегистрирован: 23.05.2013
Сообщений: 11

Re: Неизвестная причина падения mysql

paulus написал:

960 подключенных соединений. Никто не смотрит, сколько, собственно, из них работали?

А кто должен смотреть, что посоветуете?

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson