Can't connect to local MySQL server through socket (11)

S3
На сайте с 16.11.2010
Offline
41
3190

Здравствуйте!

У меня немножко нестандартная проблема.

Имеется сервер с большим онлайном (8к-9к человек, судя по гугл.аналитике). И когда цифра переваливает за 6500 онлайна, до mysql становится сложно достучаться, а конкретнее рандомно валится вот с такой фигней:


SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (11)

В качестве сервера - percona, и она сама по себе чувствует себя нормально, да и сервер ЛА вполне милый - от 0 до 4.

Исходя из этого, у меня большие подозрения на конфигурацию именно системы. Вчера проштудировал параметры ядра, в частности поднял количество тредов, количество открытых сокетов, уменьшил время ожидания соединения tcp/ip, и поднял спокойный онлайн до 6500 человек (раньше такая ошибка вываливаться начинала уже при 3500).

Дальше не знаю уже что делать. Поэтому и прошу помощи у вас.

Предположение, что именно ему сокетов и не хватает.


$ ss -s
Total: 8650 (kernel 9002)
TCP: 8513 (estab 7732, closed 469, orphaned 20, synrecv 0, timewait 467/0), ports 0

Transport Total IP IPv6
* 9002 - -
RAW 0 0 0
UDP 10 6 4
TCP 8044 8040 4
INET 8054 8046 8
FRAG 0 0 0

Сейчас онлайн 2500, при 7500 цифры немного другие(примерно такие, пишу по памяти):


TCP: 28004 (estab 28004, closed НЕ_ПОМНЮ, orphaned 20, synrecv 0, timewait 2300/0), ports 0


$ cat my.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld]
user = mysql
port = 3306
socket = /var/run/mysqld/mysqld.sock
pid-file = /var/run/mysqld/mysqld.pid
tmpdir = /tmp
basedir = /usr
datadir = /home/mysql

skip-external-locking
bind-address = 127.0.0.1

key_buffer = 1024M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 16
read_buffer_size = 1M
sort_buffer_size = 64K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
max_connections = 400

query_cache_limit = 1M
query_cache_size = 16M

table_cache = 4096
open_files_limit = 65535
tmp_table_size = 256M
max_heap_table_size = 1024M

group_concat_max_len = 65535

log_error = /var/log/mysql/error.log

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 5

innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_file_size = 512M
innodb_buffer_pool_size = 4G
innodb_additional_mem_pool_size = 32M
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 0
innodb_lock_wait_timeout = 15

innodb_file_per_table

До конфига my.cnf руки пока не дошли, к сожалению, поэтому показываю то, что досталось.

Напоминаю, что


$ perror 11
OS error code 11: Resource temporarily unavailable

Логи mysql, syslog, messages молчат как рыбы :-(

Не в пользу моей теории с сокетами говорит то, что выпадает только mysql, остальные приложения работают штатно.

Жду от вас предложений, буду рад любым!

Glueon
На сайте с 26.07.2013
Offline
172
#1

Для интереса не пробовали localhost менять на 127.0.0.1 в настройках? Т.е. уходить с unix сокета на TCP.

Есть много IP-сетей в аренду под прокси, парсинг, рассылки (optin), vpn и хостинг. Телега: @contactroot ⚒ ContactRoot команда опытных сисадминов (/ru/forum/861038), свой LIR: сдаем в аренду сети IPv4/v6 (/ru/forum/1012475).
A
На сайте с 19.07.2010
Offline
130
#2

запустите тюнер и покажите его вывод.

желательно чтобы mysql работал подольше перед запуском тюнера.

в вашем конфиге, я бы сразу поставил значительно больше кеш запросов

query_cache_size = 16M // хотя бы 128 - 256M

под вопросом:

key_buffer = 1024M // у вас индексы занимают 1гиг?..

tmp_table_size = 256M

max_heap_table_size = 1024M // если не ошибаюсь, то жто значение не может быть больше чем tmp_table_size (лень смотреть доку)

по диагностике тюнера многое станет понятно. возможно банально, в пиках не хватает памяти.

.............
S3
На сайте с 16.11.2010
Offline
41
#3

Итак, перевесил на 127.0.0.1.

Поднастроил сам mysql.

Еще немного пошаманил над самим сервером.

В данный момент пока не вылетает, но и народу на сайте столько нет. Следующий наплыв ожидается в воскресенье, тогда и отпишусь.

[umka]
На сайте с 25.05.2008
Offline
456
#4

Скорее всего упирается в max_connections.

Через TCP будет работать медленней, чем через unix socket. Да оно тут и ни при чём скорее всего.

Лог в помощь!
pupseg
На сайте с 14.05.2010
Offline
364
#5

max_connections

а фак.... опередели. короче - key_buffer не нужен вам такой, query_cache побольше сделайте, только не надо максимализма, и ставить туда сразу 700М

Качественная помощь в обслуживании серверов. (/ru/forum/661100) Бесплатных консультаций не даю, не помогаю, не обучаю. Минималка от 100$. Как пропатчить KDE-просьба не спрашивать. Есть форумы (http://linux.org.ru) и полезные сайты (http://www.opennet.ru/).
S3
На сайте с 16.11.2010
Offline
41
#6
'[umka:
;12151944']Скорее всего упирается в max_connections.
Через TCP будет работать медленней, чем через unix socket. Да оно тут и ни при чём скорее всего.

Это в теории, на практике - ничуть не медленней. Я, конечно, не замерял, но по ощущениям - ничего не поменялась, может быть какие-нибудь микросекунды. Почему не поможет?

Кто-то мне сказал, что мол это только сам сервер слушает порт, а общается он все равно с базами через сокет, это так? (Я еще не гуглил такую информацию)

pupseg:
max_connections
а фак.... опередели. короче - key_buffer не нужен вам такой, query_cache побольше сделайте, только не надо максимализма, и ставить туда сразу 700М

Я это знаю :-) может быть не супер тонкости mysql, но все первичные советы по настройке уже чуть ли не наизусть помню :-)

А вот max_connections


Highest connection usage: 89% (358/400)

Да и я все же подозреваю, что не в mysql дело, именно в системе, в ядре, может быть еще где-то :-(

Glueon
На сайте с 26.07.2013
Offline
172
#7

Highes connection usage у вас конечно высоковат ... Вы используете pconnect? wait_timeout не пробовали поменьше делать? Много ли sleep процессов висит?

S3
На сайте с 16.11.2010
Offline
41
#8
Glueon:
Highes connection usage у вас конечно высоковат ... Вы используете pconnect? wait_timeout не пробовали поменьше делать? Много ли sleep процессов висит?

pconnect нет, обычный mysql_connect

wait_timeout выставил сейчас в 15000

sleep'ов штук 7-12, не больше

AU
На сайте с 03.09.2009
Offline
88
#9

Как уже рекомендовали выше, запустите mysqltuner: https://github.com/major/MySQLTuner-perl/blob/master/mysqltuner.pl и покажите вывод. Много полезного можно будет узнать.

Unix в вопросах и ответах https://unixhow.com (https://unixhow.com)
S3
На сайте с 16.11.2010
Offline
41
#10

Итак, после настройки ядра и сервера mysql - БД выдержала.

Вылезли уже другие ошибки, но это тема отдельной истории, туда моя оптимизация еще не дошла.

Если в кратце подвести итог:

- mysql был поднастроен через приводившийся в этой теме mysqltuner.pl и еще в закромах у меня есть tuning-primer.sh.

- в самом ядре был прокачан стек tcp/ip, количество сокетов, выделяемой памяти и работа со swap'ом

- были поднастроены лимиты для пользователя mysql в /etc/security/limits.conf

Возможно что-то еще по мелочи, я точно не помню.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий