Ошибка соединения

[evpu]

Добрый день!
Извините товарищи, нудно пишу.

Победил предыдущую проблему, перенес клиентское приложение на другой сервер. Среда Debian 8.7 где Mysql, и он же где софт.
Софт (приложение на С) соединяется с сервером через libmysqlclient.
Пока они висели на одном локалхосте, (127.0.0.1) а так же я пробовал внешний адрес (вида 192.168.. в пределах одной машины)
все работало отлично, за исключением того что жрало ресурсы, отъедая их у mysql, в этой связи и тормозило.

Перенес софт на другой сервак, отдал mysql целый Xeon и базу на NVM-томе.
Соединил сервера прямым пачкордом через гигабитный интерфейс.
Тормозить перестало, но стали проскальзывать ошибки соединения. Иногда. Из миллиона, 1-2 (замерил).

lost connection to mysql server at 'reading authorization packet' system error 104
lost connection to mysql server at 'reading authorization packet' system error 0
mysql error can't connect to mysql server on '192.168.1.1' (99)

наблюдаю пока недолго, есть подозрение что связано таки с пиковыми нагрузками.
Серверный параметр connect_timeout == 10(повышен давно). В логах mysql этих ошибок нет. (типа aborted connections).. может не там смотрю?


Хочу в коде для начала применить опцию
mysql_options()
MYSQL_OPT_CONNECT_TIMEOUT, это уже на клиентской стороне, повысить его, посмотреть что получится. Секунд до 10.

ПРОШУ СОВЕТА ПО ВСЕМУ НАПИСАННОМУ.

И, по поводу самой команды, нагуглил несколько вариантов ее начертания, везде идет как рабочий пример:


unsigned int conn_timeout=10;
1.
mysql_options(&mysql, MYSQL_OPT_CONNECT_TIMEOUT, &conn_timeout);

2.
mysql_options(&mysql, MYSQL_OPT_CONNECT_TIMEOUT, "10");

3.
mysql_options(connection, MYSQL_OPT_CONNECT_TIMEOUT, (const char *)&conn_timeout);


Нихрена не пойму.. какой правильный???
В прототипе написано что тип аргумента, "unsigned int *".

[evpu]

Вышеописанную хрень с 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]

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

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-у было тесно, он не отвечал с такой скоростью, чтобы такое могло произойти. А на ненагруженном ничем сервере и не создавалось такого количества процессов.