MySQL

evpu · Отправлено: **11:18, 01-02-2019** | #2

Вышеописанную хрень с MYSQL_OPT_CONNECT_TIMEOUT опробовал, путем подсовывания клиенту прослушивающего порта сниффера вместо сервера mysql.

Не работает ни один вариант. И не нужно (оно и так ждет инициирущего пакета до опупения). Проблема тут видимо в другом.

В рабочем режиме mysql отрабатывает от 100 до 200 соединений в секунду, которые разрываются сразу после выполнения запроса. Будучи на localhost работает нормально. С этой же интенсивностью.

Устроил crash-тест, при котором количество соединений скакнуло предположительно вдвое, поперли ошибки
mysql error can't connect to mysql server on '192.168.1.1' (99)

Требуемые для нагруженных серверов sysctl-ы оттюнинговал. (повысил емкость буферов очереди ТСР, и все такое..)

У меня гнилое подозрение.. а не уперлось ли оно в потолок гигабитного интерфейса?..

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

evpu · Отправлено: **17:12, 07-02-2019** | #3

Уфф.. ну спасибо тем кто хоть заглянул). Ошибка хитровыдрюченная. Естественно, по внешнему описанию подсказать было нечего.

1. Пачкорд взял НОРМАЛЬНЫЙ, не 3 метра странного вида, а 40см, с экраном, обжатый самолично, качественной свивки.
2. В настройках sysctl Linux-a есть параметры отвечающие за размеры входного-выходного буфера. Их пришлось подкрутить.

В моменты пиковых нагрузок, количество соединений превышало 500(!!!) в секунду, при этом диапазон по-умолчанию динамических портов (28 тыщ портов) перебирался менее чем за 60 сек, т.е еще до того, как истекал таймаут жизни ранее закрытых.

Поэтому:

3. В софте перед mysql_real_connect поставил небольшой настраиваемый delay.
4. Расширил диапазон выдаваемых динамических портов до 4000-65000
5. уменьшил системный таймаут "net.ipv4.tcp_fin_timeout" до 15 сек.

Ушло вроде.

И ответ, почему на localhost-е не глючило - просто MySQL-у было тесно, он не отвечал с такой скоростью, чтобы такое могло произойти. А на ненагруженном ничем сервере и не создавалось такого количества процессов.