Не доходит до accept при большом количестве соединений

ulimit глянь. там по-умолчанию 1024 открытых файла обычно.

Это я уже прошел когда-то.
RLIMIT_NOFILE стоит на максимум, т.е. 4096.

до accept доходят уже не все входящие подключения

замени

listen(sock, 5)

на listen(sock, 10)

а ты посчитай, может там все дескрипторы как раз упираются в 4096? цифра-то не такая уж и большая.

Считал, не должно, т.к. суммарно сокетов 2.5к и уже это эффект в наличии.

Не помню пробовал или нет, если пробовал - не помогло.
Теоретически - т.к. все потоки висят в epoll_wait не должно упираться в это.

А Вы EPOLLET правильно обрабатываете? Попробуйте без этого флага сначала.

на linux, насколько я помню, вполне можно сделать listen(sock, 0) и должна быть бесконечная очередь. Но я не на 100% уверен.

Но если очередь переполнена - должно возвращаться ECONNREFUSED на клиенте - это можно отловить.

А как можно его не правильно обработать и в чем заключается правильность?

т.к. все потоки висят в epoll_wait не должно упираться в это.

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

В этом и суть - connect проходит на клиенте, потом уже по таймеру клиент отключается, т.к. ничего не получает от сервера в ответ.

Теоретически - т.к. все потоки висят в epoll_wait не должно упираться в это.

Посмотри netstat'ом размер очереди (Recv-Q), может накосячил где-то в обработчике и accept сокет не всегда находится в пуле.

А как можно его не правильно обработать

Например, можно оставить непрочитанными некоторые данные из дескриптора. В случае слушающего сокета можно вызвать accept() только один раз, хотя в очереди сокета уже 2 соединения, - это тоже неправильно (состояние сокета не изменилось, а значит, epoll не вернёт этот дескриптор снова).

Слушающие сокеты живут в 1й куче с входящими. Но судя по gdb потоки почти постоянно сидят на epoll_wait, а не на обработке данных, да и уже подключенные совершенно не тормозят. В epollе же нет приоритетов на подключенных и подключающихся.

ты уж определись тогда: или

connect проходит на клиенте, потом уже по таймеру клиент отключается, т.к. ничего не получает от сервера в ответ.

или

до accept доходят уже не все входящие подключения

ибо пока на сервере accept() не отработает, на клиенте connect() не завершится

давай сюда кусок кода - цикл обаботки входящих содеинений.

ибо пока на сервере accept() не отработает, на клиенте connect() не завершится

4.2

Данные читаются в полном объеме. Как тогда отследить что там 2 ожидающих соединения? Не припоминаю чтоб где-то видел записи о подобном.

http://pastebin.com/V5RWsf0t

Просто уберите флаг EPOLLET и попробуйте для начала.

Как тогда отследить что там 2 ожидающих соединения?

Вызывать accept() до опупения. Т.е. до EWOULDBLOCK. Или не использовать EPOLLET, тогда можно вызывать accept() и 1 раз.

Благодарю, вечером проверю.

4.2

ну да, не совсем так, немного наоборот
имелось ввиду, что если на клиенте connect() завершился, то без начала обработки accept() на сервере это обойтись не могло

Тогда я не могу объяснить это, connect на клиенте блокируемый, но он проходит, а лог сразу после accept на сервере происходит с заметным опозданием.

что если на клиенте connect() завершился, то без начала обработки accept() на сервере это обойтись не могло

Это тоже не так.

connect на клиенте блокируемый, но он проходит, а лог сразу после accept на сервере происходит с заметным опозданием.

accept() завершается позже завершения connect()?
разное время на клиенте и сервере, лог буферизируется где-то

Это тоже не так.

ну-ка расскажи...
конечно, завершение connect() с -1 и errno==EINPROGRESS не считается

После. Время правильное. Буферизация вывода в stdout вообще отключена, да и в файл сразу fflush после записи.

Заранее сообщаю что на клиенте -1 достаточно чтоб считать подключение не удавшимся. Но connect проходит с успехом.

сколько?

Сколько что? Время на клиенте = время на сервере.

на сколько после? так и должно быть «после»; проблема то, видимо, в «гораздо»? или в чем?

До 40 секунд, дальше уже клиент по таймеру отключается.

На случай чего - tcpdump на сервере показывает попытку подключения сразу.

т.е SYN приходит сразу? смотри дальше когда уходит SYN+ACK, а потом еще когда от клиента приходит ACK
если последний ACK приходит тоже сразу, то проблема с его обработкой на сервере — вторая фаза accept(), если ACK задерживается, то проблема на клиенте или в транспорте

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

Обновил логи - даже до 6 подключений в 1 событии дошло уже.

Поднял listen до 16 - видел и 16 accept'ов за событие.