freebsd - не могу выжать больше 250 мегабит!

winger · May 30, 2012

Суть проблемы: имею сервер intel , на борту встроенный двухпортовый сетевой адаптер, определяется как em. CPU xeon 5200 двухядерный. 2 GB oper.

На сервере установлен udpxy+nginx. Задача принять multicast с одного интерфейса и отдать unicast http через nginx и другой интерфейс. Проблема в том что при достижении выхода в 250 мегабит\с начинаются жуткие тормоза, трафик резко падает до 50 и смотреть невозможно. Включал polling, тюнил sysctl, много что делал. Что нужно выложить скажите выложу. Help :(

s.lobanov · May 30, 2012

версия nginx? На старых были проблемы с потоковым видео(текла память)

winger · May 30, 2012

версия nginx? На старых были проблемы с потоковым видео(текла память)

Да действительно, есть такие проблемы на версиях вплоть до 1.2.0, на ней вроде не течет. 1.2.0 использует всего около 40 метров памяти и не растет почему от количества юзеров.....

s.lobanov · May 30, 2012

нужен более-менее новый nginx и в конфиге прописать chunked_transfer_encoding off; после этого связка nginx<->vlc/updxy нормально работает(на linux-е, но думают, что не в ОС тут дело)

winger · May 30, 2012

Все прописано! Думаю что дело не в nginx. Однако если у вас есть такая связка не могли бы вы поделиться той частью конфига nginx где настраиваете буфера и т.д. Какой макс. траф у вас в ЧНН?

s.lobanov · May 30, 2012

сейчас никакого трафика нет. делал одну трансляцию в паблик интернет как-то раз, там трафика было ~400мбит/с в пике. конфига не осталось, только заметка о версии nginx и параметре chunked_transfer_encoding. в sysctl что-то выкручивал про tcp, но там был linux, а тут как раз и разница

Ivan_83 · May 30, 2012

Отдаём прямо с udpxy.

Под линухом.

Тюнил TCP: конгнешн контрол алгоритм поставил: htcp, и увеличил буфера, типа до 16мб.

На фре можно сделать тоже самое. cc в 9.0 точно есть, вероятно и в 8.2 тоже.

Клиентов пока мало, в пике видел 40. Поток в среднем по 4 мегабита на канал.

Покажите:

top -aCSPIH

uname -a

PS: в планах есть сделать свой udpxy, в котором будет кольцевой буфер на канал, возможность задавать размер прекеширования и который не будет форкатся на каждого клиента - те всё счастье сразу.

winger · May 30, 2012

Попробовал забрать напрямую с UDPXY в момент когда начинаются тормоза - идет нормально!!! Похоже был неправ.... Видимо дело в нгинкс... Пробовались все версии начиная с 1.0.0 и выше....

last pid: 7734; load averages: 0.09, 0.18, 0.25 up 0+02:23:29 20:15:40

158 processes: 3 running, 137 sleeping, 18 waiting

CPU 0: 0.0% user, 0.0% nice, 1.0% system, 0.0% interrupt, 99.0% idle

CPU 1: 0.0% user, 0.0% nice, 2.9% system, 0.0% interrupt, 97.1% idle

Mem: 98M Active, 1590M Inact, 156M Wired, 9596K Cache, 112M Buf, 141M Free

Swap: 2048M Total, 64K Used, 2048M Free

PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND

11 root 171 ki31 0K 8K RUN 1 117:39 100.00% [idle: cpu1]

12 root 171 ki31 0K 8K RUN 0 116:02 100.00% [idle: cpu0]

7343 nobody 4 0 38396K 34104K kqread 1 0:40 2.59% nginx: worker pr

15 root -44 - 0K 8K WAIT 1 16:22 0.29% [swi1: net]

Но это когда работает норм, когда начинаются тормоза поле PRI показывает минуса (типа -44, -8 и т.д.)

FreeBSD line 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Wed May 30 17:27:03 MSD 2012 winger@line:/usr/src/sys/i386/compile/MY3 i386

Ivan_83 · May 30, 2012

Обновите систему, для начала.

s.lobanov · May 30, 2012

winger

Кстати, а у вас зачем нужен frontend в виде nginx? Ради безопасности/прямоты ссылок/логов/балансера/...?

P.S. переходите на тёмную сторонуlinux, чтобы решать проблемы на фряхе надо самому быть программистом

nuclearcat · May 30, 2012

Обновите систему, для начала.

На Линукс :)

</troll>

winger · May 31, 2012

Спасибо всем отписавшимся! Попробую на linux 64, на такой же машине... Отпишусь о результатах....

martini · May 31, 2012

ну вот еще одного перетянули на тёмную сторону линукссс )

Ivan_83 · May 31, 2012

nginx под линуксом не нативен, и ряда плюшек просто в линуксе не существует. (kqueue vs epoll)

udpxy - пофик где работать, там примитивная модель IO с форками.

nuclearcat · May 31, 2012

kqueue и epoll практически равны по производительности

nginx практически одинаково функционирует под обеими OS и поддерживает "advanced" фиги обеих.

Ivan_83 · May 31, 2012

Это как вы замерили что они равны?)

kqueue:

- возвращает сразу код ошибки;

- количество байт которые можно записать/прочитать;

- описатель(дескриптор) и отдельно привязанные к нему данные (указатель);

- позволяет привязать к разным операциям(фильтрам событий: запись/чтение/таймер/...) различные пользовательские данные;

- кроме записи/чтения ещё умеет таймер, сигналы, вноды и пр;

- позволяет влить в ядро сразу пачку заданий, а не по одному их туда пихать;

epoll:

- возвращает данные привязанные к описателю (но не сам описатель) и маску: запись/чтение/ошибка/hup

И по фичам:

- в линухе аккепт фильтр просто на какие то данные, во фре конкретно на хттп запрос;

- в линухе sendfile не умеет отправлять данные из буфферов до и после файла;

В итоге, если нужно быстро сляпать на посмотреть берём линукс (минимальный рабочий код будет с epoll меньше, чем во фре с kqueue). Когда нужно оптимизировать юзерспейс код на производительность и на обработку ошибок и всяких разных ситуаций то выкидываем линукс и пишем под фрёй.

Получить из epoll (плюс ещё кучки системных вызовов в придачу) хотя бы близкий аналог kqueue - огромная проблема, сделать из kqueue epoll - не сложно.

mousus · May 31, 2012

прошу прощения за дилетантский вопрос: а udpxy насколько стабильно и под чем лучше работает? какой максимальный аптайм его процесса удалось достичь и при каких нагрузках если не секрет?

Ivan_83 · May 31, 2012

Я ни разу не видел чтобы он падал (за пол года, примерно). Там и падать нечему. Работает примерно одинаково под всеми ОС (там почти базовый POSIX API для сети).

Многое зависит от тюнинга самой ОС.

Про аптайм смысла говорить нет: там родительский процесс который принимает соединения и умеет отдавать только статистику, всё что связано с ретрансляцией мультикаста форкается в отдельный процесс.

mousus · May 31, 2012

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

Ivan_83 · May 31, 2012

Пока хватит ресурсов в системе.

Зависит от многих факторов:

- память (быстродействие), кеш, количество ядер;

- тюниг системы;

- битрейт одного канала;

- другие задачи исполняемые этим же сервером.

Эту софтину ставят даже во всякие роутеры в стандартных поставках и энтузиастких прошивках. Вчера видел в асус 520gc.

Там на слабеньком арм проце и почти без памяти оно умудряется вполне работать.

Мой совет: больше 16-32 кб памяти софтине не давать под буфера использовать (один из ключей запуска), потому что толку почти нет, и начинается сплошной вред:

- излишний расход памяти;

- неравномерная отдача;

- при слабом проце/сильной загрузке могут появится заикания интервалом с то что влазит в буффер.

При слишком маленьком буфере - 4кб (дефолт) send вызывается чаще, чем с случае 16-64, а это лишняя нагрузка на проц, которая ничего не даёт.

Плюс я её патчил для того чтобы она делала прекеш: принудительно кешировала N килобайт (500-700), потом сразу их отправляла и дальше работала как обычно по n килобайт (из параметров ком строки). С таким патчем и тюнингом ОС наши медиаплееры (на реалтеке 1077дд+) в 98% случаев запускают звук без проблем (заиканий или вообще отсутствие).

nuclearcat · May 31, 2012

Это как вы замерили что они равны?)

Посмотрел бенчмарки

agr · June 1, 2012

kqueue:

- возвращает сразу код ошибки;

что значит сразу?

epoll:

- возвращает данные привязанные к описателю (но не сам описатель) и маску: запись/чтение/ошибка/hup

А что есть в этих "данных" ?

Ivan_83 · June 1, 2012

Это значит что kqueue возвращает сразу структуру с кучей данных, где есть всё что нужно.

http://www.freebsd.o...ult&format=html

http://linux.die.net/man/2/epoll_ctl

typedef union epoll_data

по факту uint64_t u64 (привязанные данные) и uint32_t events - битовая маска того что типа случилось с описателем, сам описатель не возвращается.

Те в сравнении с kqueue почти нихера. Если нужно на чтение и запись разные данные/обработчики вешать - нужно дублировать описатель...

nuclearcat · June 1, 2012

Ivan_83m вы невнимательно читаете

          typedef union epoll_data {
              void        *ptr;
              int          fd;
              uint32_t     u32;
              uint64_t     u64;
          } epoll_data_t;

          struct epoll_event {
              uint32_t     events;      /* Epoll events */
              epoll_data_t data;        /* User data variable */
          };

Возвращается epoll_event, там маска события, и data - указатель на виновника события. Это может быть и индекс какой-нить, и FD или даже указатель на структуру.

Ivan_83 · June 1, 2012

Возвращается epoll_event, там маска события, и data - указатель на виновника события. Это может быть и индекс какой-нить, и FD или даже указатель на структуру.

epoll:- возвращает данные привязанные к описателю (но не сам описатель) и маску: запись/чтение/ошибка/hup

Да читаю я, уже раз 50 перечитал, пока у меня под линухом заработало то что под фрю писалось с прицелом и под линухом тоже работать.

Вот сравните и прослезитесь :)

struct kevent {
    	uintptr_t ident;     	/* identifier for this event */
    	short 	filter;            /* filter for event */
    	u_short   flags;        /* action flags for kqueue */
    	u_int 	fflags;          /* filter flag value */
    	intptr_t  data;           /* filter data value */
    	void      *udata;        /* opaque user data identifier */
	};

Sign In

freebsd - не могу выжать больше 250 мегабит!

Recommended Posts

winger

s.lobanov

winger

s.lobanov

winger

s.lobanov

Ivan_83

winger

Ivan_83

s.lobanov

nuclearcat

winger

martini

Ivan_83

nuclearcat

Ivan_83

mousus

Ivan_83

mousus

Ivan_83

nuclearcat

agr

Ivan_83

nuclearcat

Ivan_83

Join the conversation