Сервер запускает на каждого клиента pthread_create. Каждый Тред слушает (select) свои 5-20 сокетов. Нагрузка - 200 клиентов/секунду (и еще планируется нарастить до 500 :). Лимит по количеству открытых файлов вроде как поднят до 8192. (__FD_SETSIZE=8192, в include/bits/typesyzes.h, incude/linux/ limits.h, fs.h, posix_types.h). Операционка Suse Linux 8.2.

И вот все это валится :(
Валится оно из-за запаривания стека.
Что следует из Backtrac-а (gdb) коры: параметр передаваемый сквозняком через несколько функций чудесным образом из 0 стает 14218471987419. Внутри функций параметр гарантировано не меняется.
Вот такая петрушка.

Максимальное значение FD засовуемое в select НЕ привышает 2000-3000 (т.е. еще далеко до 8192).

И еще, насколько я проиграю если перейду с select-а на poll?

• Проблемы со стеком при БОЛЬШОЙ загрузке сервера,Max V. Zinal, 20:17 , 23-Июл-03
  • Проблемы со стеком при БОЛЬШОЙ загрузке сервера,Murr, 15:34 , 05-Окт-03
  • Проблемы со стеком при БОЛЬШОЙ загрузке сервера,Leningrad, 16:01 , 05-Окт-03

>Сервер запускает на каждого клиента pthread_create. Каждый Тред слушает (select) свои 5-20
>сокетов. Нагрузка - 200 клиентов/секунду (и еще планируется нарастить до 500
>:). Лимит по количеству открытых файлов вроде как поднят до 8192.
>(__FD_SETSIZE=8192, в include/bits/typesyzes.h, incude/linux/ limits.h, fs.h, posix_types.h).
>Операционка Suse Linux 8.2.
>

Да вы, батенька, фашист :).
При таком количестве клиентов лучше не создавать гору потоков, а использовать
пул оных относительно небольшого размера (в любом случае не больше, чем
4 x количество_процессоров). При обнаружении по poll() либо select() активности
клиента дескриптор соединения изымается из poll()-select()ных структур и ставится
в очередь, из коей соединения конкурентно выгребают потоки, входящие в пул.
Совершив не слишком крупный квант работы, можно вернуть соединение
на прослушку, дабы обнаружить дальнейшую активность клиента.

Само собой, возможны и другие варианты. Но исходя из данного вами описания,
проще всего переделать именно на такой вариант.

>И вот все это валится :(
>[...]

Нисколько не удивлён.

>
>И еще, насколько я проиграю если перейду с select-а на poll?

На при переходе на poll() выигрыш разве что в снятии формального ограничения
на число прослушиваемых дескрипторов. Более эффективное решение - /dev/poll.

Успехов.

>На при переходе на poll() выигрыш разве что в снятии формального ограничения
>на число прослушиваемых дескрипторов. Более эффективное решение - /dev/poll.

Не было в Linux никогда /dev/poll. Есть epoll (сейчас).

> Более эффективное решение - /dev/poll.

FreeBSD и kqueue