Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Собственно, проблема вот в чем - есть сайт php\mysql, работает корректно. Около 50 пользователей одновременно онлайн.
Сервер достаточно мощный, нагрузка небольшая. В php настроен обработчик подключений к базе - письмо на почту падает в случае ошибки.
Так вот, раз в день(примерно в час пик) прилетают письма счастья с ошибкой:
Код ошибки: 2002
Сообщение: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (11)
Запрос: mysql_connect(“localhost”, “database”)
Место: /var/www/includes/DBSimple.inc.php line 6
Погуглил, ничего информативного не нашел. У большинства просто отсутствовал mysqld.sock после сбоя или были изменены права доступа.
У меня же файл /var/run/mysqld/mysqld.sock всегда на месте, с правами все порядок. Крутится на Debian
Как данный вопрос решить?
Неактивен
Что написано в логе ошибок MySQL?
Неактивен
$ perror 11
OS error code 11: Resource temporarily unavailable
Смотрите логи ошибок MySQL - не было ли рестартов сервера
Неактивен
Уже несколько дней ошибки не валились, это лог недельной давности. Как только - так скину посвежее.
150502 00:57:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150502 0:57:27 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
150502 0:57:27 [Note] Plugin 'FEDERATED' is disabled.
150502 0:57:27 InnoDB: Initializing buffer pool, size = 10.0G
150502 0:57:31 InnoDB: Completed initialization of buffer pool
150502 0:57:33 InnoDB: Started; log sequence number 5 1021344165
150502 0:57:33 [Note] Event Scheduler: Loaded 0 events
150502 0:57:33 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.66-0+squeeze1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
150502 0:57:48 [Note] /usr/sbin/mysqld: Normal shutdown
150502 0:57:48 [Note] Event Scheduler: Purging the queue. 0 events
150502 0:57:48 InnoDB: Starting shutdown...
150502 0:57:55 InnoDB: Shutdown completed; log sequence number 5 1021371512
150502 0:57:55 [Note] /usr/sbin/mysqld: Shutdown complete
150502 00:57:55 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150502 00:59:16 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150502 0:59:16 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
150502 0:59:16 [Note] Plugin 'FEDERATED' is disabled.
150502 0:59:16 InnoDB: Initializing buffer pool, size = 10.0G
150502 0:59:18 InnoDB: Completed initialization of buffer pool
150502 0:59:19 InnoDB: Started; log sequence number 5 1021371512
150502 0:59:19 [Note] Event Scheduler: Loaded 0 events
150502 0:59:19 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.66-0+squeeze1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
150601 13:29:39 InnoDB: ERROR: the age of the last checkpoint is 9433795,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
150618 4:01:00 [ERROR] Error writing file '/var/log/mysql/mysql-slow.log' (errno: 1)
150619 18:01:36 [ERROR] /usr/sbin/mysqld: Sort aborted
150709 9:57:31 InnoDB: ERROR: the age of the last checkpoint is 9433857,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
150709 9:57:51 InnoDB: ERROR: the age of the last checkpoint is 9433880,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
150709 9:59:08 InnoDB: ERROR: the age of the last checkpoint is 9433911,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
150716 9:28:00 [ERROR] /usr/sbin/mysqld: Sort aborted
150727 4:16:10 [ERROR] /usr/sbin/mysqld: Sort aborted
150728 21:52:38 [ERROR] /usr/sbin/mysqld: Sort aborted
150807 11:48:46 [Note] /usr/sbin/mysqld: Normal shutdown
150807 11:48:47 [Note] Event Scheduler: Purging the queue. 0 events
150807 11:48:49 InnoDB: Starting shutdown...
150807 11:48:59 InnoDB: Shutdown completed; log sequence number 27 51884694
150807 11:48:59 [Note] /usr/sbin/mysqld: Shutdown complete
150807 11:48:59 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150807 11:49:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150807 11:49:27 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
150807 11:49:27 [Note] Plugin 'FEDERATED' is disabled.
150807 11:49:27 InnoDB: Initializing buffer pool, size = 10.0G
150807 11:49:30 InnoDB: Completed initialization of buffer pool
150807 11:49:31 InnoDB: Started; log sequence number 27 51884694
150807 11:49:32 [Note] Event Scheduler: Loaded 0 events
150807 11:49:32 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.66-0+squeeze1-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian)
Неактивен
Перезапусков немного, попробуйте узнать еще что-то о сервере в моменты недоступности
Неактивен
Сегодня вновь все повторилось. Лог не изменился. Есть еще какие-нибудь идеи?
Неактивен
Выглядит, как забитый бэклог демона, поэтому я бы начал копать в связанные с этим стороны.
1) Почему-то в голову пришел apparmor, поэтому я бы проверил, что он не обновляется и никак не влияет на этот процесс (самый простой способ — выключить его вообще);
2) max_connections внутри демона (если вы упретесь в количество соединений, а потом забьете бэклог, то вот это прямо оно), тут, может быть, стоит как-то это рисовать;
3) на 5.1 бэклог фиксированный, но его можно поднять вручную: http://dev.mysql.com/doc/refman/5.1/en/ … r_back_log
И из общих соображений:
Лог не изменился — а сам mysqld-то при этом тот же? Посмотрите, например, на его время старта в ps. Ну и хорошо бы посмотреть, что происходит в системе в это время — может быть, что-нибудь обновляется — пакеты какие-то, еще что-то. Посмотрите на другие логи системы, если это происходит регулярно, это может быть cron.
Отредактированно paulus (14.08.2015 18:33:27)
Неактивен
Портал работает в связке с 1С, через SOAP. Я все грешу на какие-нибудь таймауты или подключения\запросы в цикле. Дело в том, что портал очень большой, в плане кода и не имеет единой точки входа, чтобы организовать отладку. Подключения\запросы раскиданы по сотням файлов. Есть график из заббикса. По нему видно, что с 16:00 до 16:09 mysql форкаться начал. Ошибка начала появляться с 16:03 до 16:07
Неактивен
Пока еще не решил свою проблему. Но обязательно отпишусь, что это было.
А пока еще один вопрос: команда top выдает у mysqld %CPU = 300-600!
Посмотрел SHOW FULL PROCESSLIST - там нет никаких суровых запросов, все выполняются очень быстро. Откуда такая нагрузка?
Неактивен
Проверьте, что SHOW FULL PROCESSLIST выполнено под суперпользоватем, иначе он покажет не все запросы.
В принципе нагрузка может быть из-за огромного количества быстрых запросов.
Неактивен
Суперпользователь - это рут? От него и проверял. Вся соль в том, что SHOW FULL PROCESSLIST показывает 5-20 запросов, в основном это простейшие селекты и 2-4 запроса записи. Откуда такие цифры в cpu для меня загадка.
Неактивен
root обычно является суперпользователем (если ему даны соответствующие права). Какое время исполнения запросов указано в SHOW FULL PROCESSLIST? Они точно все быстро исполняются. Посмотрите также лог - нет ли фоновых процессов по восстановлению баз и.т.д.
Неактивен
Решил вернуться к данному вопросу, т.к. он не был решен. Пришел с обновленной информацией.
У нас есть приложение, написанное на php, оно сильно завязано на SOAP. Некоторый функционал подразумевает долгие SOAP запросы(от 10с и дольше). Как я понимаю, все время, пока web сервер обрабатывает php скрипт - соединение с базой открыто.
Ситуация следующая - когда много клиентов заходят в медленный функционал, у нас начинают открываться thread базы. В определенный момент начинает сыпаться ошибка:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11)
При этом:
1) mysql работает!
2) SHOW FULL PROCESSLIST - почти чист (нет медленных\зависших\блокирующих запросов)
paulus написал:
Выглядит, как забитый бэклог демона, поэтому я бы начал копать в связанные с этим стороны.
1) Почему-то в голову пришел apparmor, поэтому я бы проверил, что он не обновляется и никак не влияет на этот процесс (самый простой способ — выключить его вообще);
Не используем
paulus написал:
2) max_connections внутри демона (если вы упретесь в количество соединений, а потом забьете бэклог, то вот это прямо оно), тут, может быть, стоит как-то это рисовать;
max_connections = 3000 (увеличение является выходом из ситуации, но память у сервера не резиновая)
back_log = 3000 (по ощущениям - не реагирует на это, т.к. ошибки валятся при наборе max_connections > 3000)
paulus написал:
3) на 5.1 бэклог фиксированный, но его можно поднять вручную: http://dev.mysql.com/doc/refman/5.1/en/ … r_back_log
Как раз таки используем 5.1, Debian
В настройках системы поставил следующие значения:
somaxconn = 15000
netdev_max_backlog = 15000
tcp_max_syn_backlog = 15000
Не помогает.
Из всего понял, что упираемся в max_connections, но не понятно, почему при достижении значения back_log вроде как не используется.
Как вызываю ошибку и забиваю max_connections?
mysqlslap -u root -p --auto-generate-sql --concurrency 1500 --iterations 5 -vvv
Неактивен
Страниц: 1