форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Проблемы со стеком при БОЛЬШОЙ загрузке сервера"
Сообщение от Vladmir7 on 23-Июл-03, 16:45  (MSK)
Сервер запускает на каждого клиента 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?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Проблемы со стеком при БОЛЬШОЙ загрузке сервера"
Сообщение от Max V. Zinal on 23-Июл-03, 20:17  (MSK)
>Сервер запускает на каждого клиента 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. Успехов.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "Проблемы со стеком при БОЛЬШОЙ загрузке сервера"
	Сообщение от Murr on 05-Окт-03, 15:34  (MSK)
	>На при переходе на poll() выигрыш разве что в снятии формального ограничения >на число прослушиваемых дескрипторов. Более эффективное решение - /dev/poll. Не было в Linux никогда /dev/poll. Есть epoll (сейчас).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Проблемы со стеком при БОЛЬШОЙ загрузке сервера"
	Сообщение от Leningrad on 05-Окт-03, 16:01  (MSK)
	> Более эффективное решение - /dev/poll. FreeBSD и kqueue
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

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