Comments 35
UFO just landed and posted this here
А в 11 воспроизводится?
11.0 не тестировал. Мы её не используем — сильно падучая. Зависает под нагрузкой регулярно, бывает по несколько раз на день ;(
Какая именно версия? Кернел паники были? PR открывали?
Глючит 11.0, я ж написал, что она падучая. Паник не было, тихо, но надежно виснет, непредсказуемо, гарантированно воспроизвести не получается. PR не открывал, каюсь.
Странно, у нас 11 на 16 боевых серверах (пиковые нагрузки до 250К pps на сервер), уже пол года, никаких зависаний. У вас кроме сети и ЦПУ на что еще нагрузки в приложении? Диски?
Есть разные, виснет и на отдаче контента с дисков, и чисто сеть+проц (ну как «чисто», диски все равно используются, но уже не так интенсивно).
Возможно, у нас сильно специфический конфиг ядра, он весьма отличается от GENERIC…
Увы, x.0 релизы давно уже не выпускались сразу в продакшн качестве, та же 10-ка только к 10.3 стала более-менее безпроблемной, и все равно 9-ка часто работает лучше в одних и тех же условиях.
Надеюсь, в 11.1 много пофиксят, если зависния не уйдут — придется разбираться и с ними )
Также надеюсь, что в 11.1 добавят tcp_сс BBR, иначе в большинстве случаев будет прямой смысл ставить Linux.
Возможно, у нас сильно специфический конфиг ядра, он весьма отличается от GENERIC…
Увы, x.0 релизы давно уже не выпускались сразу в продакшн качестве, та же 10-ка только к 10.3 стала более-менее безпроблемной, и все равно 9-ка часто работает лучше в одних и тех же условиях.
Надеюсь, в 11.1 много пофиксят, если зависния не уйдут — придется разбираться и с ними )
Также надеюсь, что в 11.1 добавят tcp_сс BBR, иначе в большинстве случаев будет прямой смысл ставить Linux.
А вы все-таки гляньте 11.1, может и там этот же PR.
Это что, получается, кто-то на удаленной стороне вбрасывал FIN/RST? Похоже на какой-то вариант блокировки сайтов.
А почему решили сервер на FreeBSD а не на линукс держать?
Исторически у нас FreeBSD используется с самого начала, Linux ставили только по необходимости (если софт, например, работает под линуксом существенно лучше чем под фрей). Ещё несколько лет назад у FreeBSD с Linux был паритет — в каких-то задачах фря была существенно лучше (nginx+aio, например), в каких-то линукс.
Сейчас FreeBSD весьма отстает, увы ((
Сейчас FreeBSD весьма отстает, увы ((
Вы меня огорчаете :(
Я только вот созрел, чтобы вплотную изучать FreeBSD, до сих пор считал, что там всё намного более стандартизировано и более строго, что-ли… Изучать всё равно буду, но уже не с таким энтузиазмом.
Однако статья — супер! Читается легко и увлекательно, как детектив. Пуаро отдыхает!
Я только вот созрел, чтобы вплотную изучать FreeBSD, до сих пор считал, что там всё намного более стандартизировано и более строго, что-ли… Изучать всё равно буду, но уже не с таким энтузиазмом.
Однако статья — супер! Читается легко и увлекательно, как детектив. Пуаро отдыхает!
То, что во фре все более продуманно, чем в линуксе, это факт. И нет множества разных дистрибутивов, каждый со своими заморочками; значительное внимание уделяется обратной совместимости. Для хостинга это серьезный фактор, на самом деле.
Лично я считаю, что FreeBSD незаслуженно обделена вниманием разработчиков, многие из которых считают, что раз в Linux скомпилировалось и запустилось, то дело сделано.
Развиваться в таких условиях FreeBSD приходится куда труднее, и то, что ей это удается делать, это уже большое достижение.
Лично я считаю, что FreeBSD незаслуженно обделена вниманием разработчиков, многие из которых считают, что раз в Linux скомпилировалось и запустилось, то дело сделано.
Развиваться в таких условиях FreeBSD приходится куда труднее, и то, что ей это удается делать, это уже большое достижение.
А в чём отстаёт? Из того что вспомнится быстро
Во первых, это плохая поддержка нового оборудования. Я даже на домашнем десктопе был вынужден перейти на Linux из-за невозможности использования двух мониторов на встроенной видяхе Intel на Broadwell, хотя до этого использовал только FreeBSD. Не без проблем, конечно, но как-то их решал, а вот вопрос с видеокартой был последним гвоздем. На серверах тоже не все гладко бывает, хотя проблемы возможны везде, в том числе и под Linux. Железо приходится подбирать всегда, промахи стоят денег )
Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений, из-за которой на высокомощных серверах ресурс заканчивается гораздо быстрее, чем если они отдают тот же контент под Linux. Ставить просто больше серверов выйдет весьма дороже.
Третий очень важный фактор — отсутствие поддержки TCP congestion control algorithm BBR, который в Linux появился в прошлом году. Когда-то его запилят и во фре, но терять в качестве обслуживания клиентов все это время нельзя.
Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений, из-за которой на высокомощных серверах ресурс заканчивается гораздо быстрее, чем если они отдают тот же контент под Linux. Ставить просто больше серверов выйдет весьма дороже.
Третий очень важный фактор — отсутствие поддержки TCP congestion control algorithm BBR, который в Linux появился в прошлом году. Когда-то его запилят и во фре, но терять в качестве обслуживания клиентов все это время нельзя.
Вроде бы в FreeBSD 12.0-CURRENT портировали из линукса работу с этими видеокартами. Но таки да, все весьма плохо. У меня вот Radeon HD8400 RS (интегрированная) в линуксе прекрасно работает на свободном amdgpu из коробки, а во фре — нет.
Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений
Довольно спорное заявление. Админю сервер для сайта одной из популярных украинских СМИ. В пике трафик доходит до гигобита/сек при огромном количестве коннектов. И никаких проблем нет. проц не отъедается.
А еще NetFlix прокачивает до 100 Gbps на дефолтном TCP стеке:
At this point, we’re able to serve 100% TLS traffic comfortably at 90 Gbps using the default FreeBSD TCP stack.
UFO just landed and posted this here
У FreeBSD есть одна весьма неприятная особенность в сетевом стеке — он плохо масштабируется относительно кол-ва TCP-сессий :(. Увеличение кол-ва TCP-сессий в несколько раз приводит к непропорционально большему потреблению CPU.
У Сысоева так всё нормально работало ещё в рамблере.
Честно говоря, не понимаю, каким образом тот факт, что у Игоря Сысоева все работало нормально, опровергает то, что нагрузка на CPU растет быстрее, чем нагрузка на сеть.
Похоже вы просто не умеете его готовить.
Вам виднее, конечно же ))
Со своей стороны могу заметить, что я ещё в 2007 году запускал больше 1.2Гбита на apache!!! 1.2 (с 4-х обычных sata дисков, ssd не было), когда ещё слово nginx никто не слышал ) Сами понимаете, какие в то время были процессоры.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=113885 — тоже пришлось в ядре покопаться, чтобы диски нормально отдавали контент.
1. Сетевая карта с MSI-X аппаратно умеет разбрасывать конекты по прерываниям.
2. Если карта унылая (ну типа там рылотек) то можно практически тоже самое делать через net.isr.dispatch=deferred, при этом схема будет такой: обработчик прерывания будет по быстрому сваливать пакеты в очередь netisr а та их сама раскладывать по ядрам. При этом ещё не плохо бы и сами очереди увеличить, чтобы за время между прерыванием/разгребанием не успевало переполнится. netstat в помощь.
Приятно видеть, что Вы хорошо владеете теорией. Проблемы же, как обычно бывает, находятся в практике )
Жуть. Я думал полинг с ядра давно выкинули. )
Сейчас, когда меньше 8 ядер на сервере уже трудно найти, в поллинге особого смысла уже нет. Но все же не стоит забывать, что процессорные ядра занимаются не столько вычислениями, сколько обменом данными, а с этим есть определенные проблемы. За счет того, что все нужные данные находятся в одном и том же кеше одного ядра, в режиме поллинга на обработку условных 10М пакетов тратится 1с работы одного ядра, а в режиме MSI-X на десятке ядер это может быть уже суммарных 5с работы одного ядра.
Далеко не факт что возьмут, как минимум оно не под 11, а лучше бы под 12
Не вижу, как эти три строчки одной проверки могут вдруг оказаться несовместимыми с 11-кой или 12-кой )
Потому что nginx пилят под фрю, а линух так, вторично.
Исключая пул IO-тредов, да? )
UFO just landed and posted this here
А можете подсказать по возникшим проблемам во фре?
1) Делал ptrace песочницу. Мне не хватило того что есть в линухе __WNOTHREAD и PTRACE_O_TRACESYSGOOD кажется. Для корректной работы с тредами и сигналами. Нашел systrace, но тоже не понял как корректно работать с тредами.
2) По поводу kqueue, с точки зрения пользователя все здорово и удобно. А вот попытался я драйвер сделать, и у меня вопросы по методам накопления эвентов в ядре. Для epoll все просто, все дескрипторы преаллоцированы, для всего остального можно дропать. А при kqueue, если приложение залипнет на секунду, на две? Сколько и каких эвентов накапливать попадающих в фильтр? Там же переполнение может возникнуть.
3) Пробелма не софсем про фрю, пробовал только на маке — dtrace буфера не гарантированно доставляются, особенно если начать уменьшать размер буфера. Соответственно я не могу на него рассчитывать, если что-то надо посчитать точно, или протрейсить вызовы, особенно если хочется развернуть то что по ссылкам структур, как это делает strace. Вот мой костыль, чтобы хотя бы аргумент execve() достать https://github.com/lieff/mac_exectrace
1) Делал ptrace песочницу. Мне не хватило того что есть в линухе __WNOTHREAD и PTRACE_O_TRACESYSGOOD кажется. Для корректной работы с тредами и сигналами. Нашел systrace, но тоже не понял как корректно работать с тредами.
2) По поводу kqueue, с точки зрения пользователя все здорово и удобно. А вот попытался я драйвер сделать, и у меня вопросы по методам накопления эвентов в ядре. Для epoll все просто, все дескрипторы преаллоцированы, для всего остального можно дропать. А при kqueue, если приложение залипнет на секунду, на две? Сколько и каких эвентов накапливать попадающих в фильтр? Там же переполнение может возникнуть.
3) Пробелма не софсем про фрю, пробовал только на маке — dtrace буфера не гарантированно доставляются, особенно если начать уменьшать размер буфера. Соответственно я не могу на него рассчитывать, если что-то надо посчитать точно, или протрейсить вызовы, особенно если хочется развернуть то что по ссылкам структур, как это делает strace. Вот мой костыль, чтобы хотя бы аргумент execve() достать https://github.com/lieff/mac_exectrace
UFO just landed and posted this here
BBR требует ко всему ещё и возможность отсылать пакеты через указанные интервалы, во фре такой функциональности пока нет, а в линуксе для корректной работы BBR надо дополнительно настраивать tc (traffic control)
Да, htcp лучший CC на фре на текущий момент, использую его с самого начала.
Да, htcp лучший CC на фре на текущий момент, использую его с самого начала.
Проблема в том, что один добавленный эвент в kqueue — на самом деле фильтр, который может генерировать много разных эвентов в сек. Например можно добавить:
Всего 2 эвента, но при этом начнут накапливаться пачки ke->filter == EVFILT_VNODE, ke->fflags & NOTE_* (и агрегировать их нельзя, т.к. у них разные ke->data) в перемешку с ke->filter == EVFILT_SIGNAL.
Вот надежного решения этой проблемы я и не вижу.
EV_SET(ke, fd, EVFILT_VNODE, EV_ADD | EV_CLEAR, NOTE_DELETE | NOTE_*..., 0, NULL);
EV_SET(ke + 1, SIGXXX, EVFILT_SIGNAL, EV_ADD, 0, 0, NULL);
Всего 2 эвента, но при этом начнут накапливаться пачки ke->filter == EVFILT_VNODE, ke->fflags & NOTE_* (и агрегировать их нельзя, т.к. у них разные ke->data) в перемешку с ke->filter == EVFILT_SIGNAL.
Вот надежного решения этой проблемы я и не вижу.
10 раз обсудить решение потом протестить и закоммитить а не переписывать 100500 как в линухе местами (про skbuf)
У меня три знакомых были коммитерами ещё со времен 4ки. И все оценивают уровень бюрократии и бесполезных "согласований" как заоблачный. Как сказал, бывший начальник: "там все хуже чем в Debian". Хотя по мне куда уж хуже, блин.
Думаю именно ваш спицифический подход к разработке отпугивает других разработчиков и уменьшает базу пользователей.
Sign up to leave a comment.
Как пропатчить K̶D̶E̶ TCP-стек под FreeBSD