|
Задавайте вопросы, мы ответим
Вы не зашли.
Приветствую.
Периодически падает 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
Неактивен
В логе MySQL интересно то, что было до тех строк, которые Вы написали. Иначе тут видно, что monit перезапустил MySQL, ну и он корректно перезапустился. Может быть багой monit, может быть какой-то другой багой. Было бы здорово посмотреть, в чем проблема, и не давать monit перезапускать. Без диагностики понять, что не так, — сложно.
Неактивен
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)
Неактивен
Ну то есть в логе MySQL никаких проблем не видно. Это хорошо. Давайте разбираться с монитом — как у него организована проверка? Может быть так, что там какой-то очень небольшой таймаут, а во время бэкапа база нагружена, и не успевает ответить за этот таймаут?
Неактивен
paulus написал:
Ну то есть в логе MySQL никаких проблем не видно. Это хорошо. Давайте разбираться с монитом — как у него организована проверка? Может быть так, что там какой-то очень небольшой таймаут, а во время бэкапа база нагружена, и не успевает ответить за этот таймаут?
if failed unixsocket /var/lib/mysql/mysql.sock protocol MYSQL then restart
Когда делаю бекап через mysqldump - проблем не возникает
Отредактированно mmx (06.12.2016 15:00:17)
Неактивен
Если всё так, то MySQL перестает слушать mysql.sock. Это так? Можете какой-то другой утилитой проверить?
Неактивен
Сегодня такое в логе обнаружил:
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
Неактивен
Вот в этом месте он точно убился. 960 подключенных соединений. Никто не смотрит, сколько, собственно, из них работали? Было бы здорово на это посмотреть. И убедитесь, что все выделения памяти осмысленно стоят. Вряд ли у Вас на сервере 650 гигабайт ОЗУ.
Кстати, если это действительно нехватка памяти и пришел ООМ, то про это должна быть запись в dmesg сервера.
Неактивен
paulus написал:
960 подключенных соединений. Никто не смотрит, сколько, собственно, из них работали?
А кто должен смотреть, что посоветуете?
Неактивен
