Re: про Reverse Connect

Peter Didenko wrote:

>> А никак. Даже не пробовали. Вот они, как раз, судя по всему - 
>> потихоньку загибаются. Что очень жалко.

Пришлось экстренно мигрировать с FreeBSD5 на FreeBSD6. "Пятерка" начала   застревать примерно раз в сутки просто так; кроме того были проблемы с производительностью и устойчивостью RAID на amr(4). "Шестерка" показала себя с наилучшей стороны. На скорость и стабильность жалоб нет. em(4) работает в режиме <RXCSUM,TXCSUM,POLLING>, то есть сетевая карта за uptime нагенерила ядру 1 interrupt и сама считает checksum'ы. amr(4) переписан с нуля и стал быстрее в несколько раз.

Однако, любая система требует тонкой настройки в интересах приложения. Например, дефолтный sysctl ставит вполне разумное ограничение kern.threads.max_threads_per_proc: 1500. Это не для CGatePro! Каждый Windows Messenger, подключаясь по TCP, садится в персональный thread и держит его круглосуточно. Если клиенты с WM забивают весь лимит (у нас так и было), все остальные службы, нуждающиеся в новых нитках, застревают с ошибкой unable to create thread и ждут прихода. Когда пяток WM отваливается, новые нитки создаются, принимают шквал запросов и устраивают серверу stress test. "Пятерка" такого стресса не переносила.

Лет десять назад во freebsd-questions случился страшный flame на тему "если не знаешь как патчить ядро -- не запускай ircd". OS FreeBSD за эти годы кое-что приобрела, но IRC-серверы так и работают в режиме listen-accept-pthread_create. Хорошо хоть не fork, прости оспади.

-- 

Герман Мызовский,
Tario Communications.

P.S. Когда обнаружилось, что amr для Solaris/Intel портирован из 
FreeBSD4, я принял решение поставить оригинальную OS.