Комментарии (31)

1. 

   alexkunin

   16.06.2017 22:21

   #10268914

   +5

   Мой любимый пятничный жанр — расследование на боевых серверах, да еще с полным хэппи-эндом в виде установленной причины и небольшим ядерным порно на Си. Я не все понял, но я вам аплодирую. (Стоя. (На столе.))

   
   

   1. 

      zuborg

      17.06.2017 08:23

      #10269208

      Право же, не стоит ))
      Рад что Вам понравилось, надеюсь, статья также попадется на глаза и другим пострадавшим пользователям FreeBSD, ведь эта индийская MiTM прокси до сих пор активна и отсылает неправильные TCP-пакеты…

1. 

   robert_ayrapetyan

   16.06.2017 22:36

   #10268940

   А в 11 воспроизводится?

   
   

   1. 

      zuborg

      17.06.2017 08:24

      #10269210

      11.0 не тестировал. Мы её не используем — сильно падучая. Зависает под нагрузкой регулярно, бывает по несколько раз на день ;(

      
      

      1. 

         click0

         17.06.2017 13:41

         #10269362

         Какая именно версия? Кернел паники были? PR открывали?

         
         

         1. 

            zuborg

            17.06.2017 14:38

            #10269406

            Глючит 11.0, я ж написал, что она падучая. Паник не было, тихо, но надежно виснет, непредсказуемо, гарантированно воспроизвести не получается. PR не открывал, каюсь.

            
            

            1. 

               robert_ayrapetyan

               17.06.2017 17:49

               #10269524

               Странно, у нас 11 на 16 боевых серверах (пиковые нагрузки до 250К pps на сервер), уже пол года, никаких зависаний. У вас кроме сети и ЦПУ на что еще нагрузки в приложении? Диски?

               
               

               1. 

                  zuborg

                  17.06.2017 21:18

                  #10269660

                  Есть разные, виснет и на отдаче контента с дисков, и чисто сеть+проц (ну как «чисто», диски все равно используются, но уже не так интенсивно).
                  Возможно, у нас сильно специфический конфиг ядра, он весьма отличается от GENERIC…
                  
                  Увы, x.0 релизы давно уже не выпускались сразу в продакшн качестве, та же 10-ка только к 10.3 стала более-менее безпроблемной, и все равно 9-ка часто работает лучше в одних и тех же условиях.
                  Надеюсь, в 11.1 много пофиксят, если зависния не уйдут — придется разбираться и с ними )
                  Также надеюсь, что в 11.1 добавят tcp_сс BBR, иначе в большинстве случаев будет прямой смысл ставить Linux.

            
            

            1. 

               click0

               17.06.2017 20:30

               #10269624

               А вы все-таки гляньте 11.1, может и там этот же PR.

               
               

               1. 

                  zuborg

                  17.06.2017 21:20

                  #10269664

                  Ребята из net-team и сами разберутся, проблема весьма специфическая, просто так её не заметить, так что шансов, что её уже исправили немного.

                  
                  

                  1. 

                     click0

                     17.06.2017 21:29

                     #10269668

                     На данный момент, в PR и freebsd-net@ нет активности по этому событию.

                     
                     

                     1. 

                        click0

                        17.06.2017 21:33

                        #10269670

                        Как ниже Иван заметил, нужна проверка в 11-HEAD или даже в 12-HEAD, чтоб коммитеры озаботились проблемой.

1. 

   miga

   17.06.2017 11:08

   #10269290

   +1

   Это что, получается, кто-то на удаленной стороне вбрасывал FIN/RST? Похоже на какой-то вариант блокировки сайтов.

   
   

   1. 

      Loiqig

      17.06.2017 11:46

      #10269306

      И возможно даже на попытку обхода, если обмен продолжается то удалённая сторона у себя-то сессию тоже не закрыла или игнорировала FIN/RST. Возможно ошибка реализации, т.е. FIN/RST MiTM системы улетают только в одну сторону сервера, но не клиента.

1. 

   technic93

   17.06.2017 18:48

   #10269580

   А почему решили сервер на FreeBSD а не на линукс держать?

   
   

   1. 

      zuborg

      17.06.2017 21:09

      #10269650

      Исторически у нас FreeBSD используется с самого начала, Linux ставили только по необходимости (если софт, например, работает под линуксом существенно лучше чем под фрей). Ещё несколько лет назад у FreeBSD с Linux был паритет — в каких-то задачах фря была существенно лучше (nginx+aio, например), в каких-то линукс.
      Сейчас FreeBSD весьма отстает, увы ((

      
      

      1. 

         AVX

         18.06.2017 23:13

         #10270378

         Вы меня огорчаете :(
         Я только вот созрел, чтобы вплотную изучать FreeBSD, до сих пор считал, что там всё намного более стандартизировано и более строго, что-ли… Изучать всё равно буду, но уже не с таким энтузиазмом.
         Однако статья — супер! Читается легко и увлекательно, как детектив. Пуаро отдыхает!
         

         
         

         1. 

            zuborg

            19.06.2017 01:57

            #10270456

            То, что во фре все более продуманно, чем в линуксе, это факт. И нет множества разных дистрибутивов, каждый со своими заморочками; значительное внимание уделяется обратной совместимости. Для хостинга это серьезный фактор, на самом деле.
            Лично я считаю, что FreeBSD незаслуженно обделена вниманием разработчиков, многие из которых считают, что раз в Linux скомпилировалось и запустилось, то дело сделано.
            Развиваться в таких условиях FreeBSD приходится куда труднее, и то, что ей это удается делать, это уже большое достижение.

      
      

      1. 

         rumanzo

         19.06.2017 01:40

         #10270448

         А в чём отстаёт? Из того что вспомнится быстро

         
         

         1. 

            zuborg

            19.06.2017 02:13

            #10270460

            +1

            Во первых, это плохая поддержка нового оборудования. Я даже на домашнем десктопе был вынужден перейти на Linux из-за невозможности использования двух мониторов на встроенной видяхе Intel на Broadwell, хотя до этого использовал только FreeBSD. Не без проблем, конечно, но как-то их решал, а вот вопрос с видеокартой был последним гвоздем. На серверах тоже не все гладко бывает, хотя проблемы возможны везде, в том числе и под Linux. Железо приходится подбирать всегда, промахи стоят денег )
            
            Второе — это вышеупомянутая проблема TCP-стека FreeBSD с большим кол-вом соединений, из-за которой на высокомощных серверах ресурс заканчивается гораздо быстрее, чем если они отдают тот же контент под Linux. Ставить просто больше серверов выйдет весьма дороже.
            
            Третий очень важный фактор — отсутствие поддержки TCP congestion control algorithm BBR, который в Linux появился в прошлом году. Когда-то его запилят и во фре, но терять в качестве обслуживания клиентов все это время нельзя.

1. 

   Ivan_83

   17.06.2017 21:10

   #10269652

   +1

   У FreeBSD есть одна весьма неприятная особенность в сетевом стеке — он плохо масштабируется относительно кол-ва TCP-сессий :(. Увеличение кол-ва TCP-сессий в несколько раз приводит к непропорционально большему потреблению CPU.

   
   Похоже вы просто не умеете его готовить. У Сысоева так всё нормально работало ещё в рамблере.
   
   

   Пока сессий немного, то проблем нет, но начиная с нескольких десятков тысяч активных TCP-сессий обработчик входящих пакетов начинает испытывать нехватку CPU и ему приходится дропать пакеты. А это приводит к цепной реакции — из-за потерь пакетов активные TCP-сессии начинают медленно обслуживаться, их кол-во начинает немедленно расти, а с ним растет и нехватка CPU и уровень потерь пакетов.

   
   Собственно указывает что тюнить вы не умеете.
   1. Сетевая карта с MSI-X аппаратно умеет разбрасывать конекты по прерываниям.
   2. Если карта унылая (ну типа там рылотек) то можно практически тоже самое делать через net.isr.dispatch=deferred, при этом схема будет такой: обработчик прерывания будет по быстрому сваливать пакеты в очередь netisr а та их сама раскладывать по ядрам. При этом ещё не плохо бы и сами очереди увеличить, чтобы за время между прерыванием/разгребанием не успевало переполнится. netstat в помощь.
   
   Там ещё десятки интересных крутилок в net.inet.tcp которые влияют на скорость работы TCP.
   
   

   пришлось оставить polling режим, но активировать idlepoll — теперь одно ядро процессора было занято исключительно сетевой картой

   
   Жуть. Я думал полинг с ядра давно выкинули. )
   
   

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

   
   Пакет фин значит только что данных не будет/можно не ждать. Это не означает что их не надо отправлять.
   Собственно shutdown() на сокете умеет указывать такие штуки. Half closed соединения.
   На практике встречается редко, под вендой я видел как матроскасплиттер делал халфклосед при воспроизведении .ts с хттп линка.
   Типичная ошибка в том, что программист видит что получено 0 байт и EOF, он думает что соединение счастливо завершилось, а на самом деле клиент просто сделал shutdown(SEND) и ждёт данных от сервера.
   
   

   PR (problem report) разработчикам FreeBSD отправлен в тот же день: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219991

   
   Далеко не факт что возьмут, как минимум оно не под 11, а лучше бы под 12.
   Да и по логике/идеологии работы тцп не факт что правильно делать как сделано в патче.
   Я добавил себя и народ с нетфликса кто тцп пилит вроде как.
   
   

   Как с этой проблемой обстоят дела в Linux и Windows?

   
   Когда то я был вынужден жить с глюкотиком в качестве домашнего роутера.
   Сидел я тогда под вендой 7, и у меня как раз бывало очень похожее поведение: комп с вендой вроде как давно уже даже ребутнулся а в торче видно что летят ретрансмиты по какой то давно не нужной TCP сессии. Какой то дос самого на себя получался.
   Разбираться не стал, и так было понятно что виноват глюкотик, а он мало того что под линухоам так ещё и исходники закрыты.
   
   2 technic93
   Потому что nginx пилят под фрю, а линух так, вторично.

   
   

   1. 

      zuborg

      17.06.2017 23:01

      #10269716

      У 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-тредов, да? )

      
      

      1. 

         cadmi

         19.06.2017 20:04

         #10272110

         ещё в 2007 году запускал больше 1.2Гбита на apache!!! 1.2 (...), когда ещё слово nginx никто не слышал

         
         
         Вот это сейчас довольно обобщающе вышло :) у меня на файлопомойке nginx в 2004 году стоял :)

         
         

         1. 

            zuborg

            20.06.2017 06:53

            #10272652

            У меня был не тот случай, когда можно было позволить использовать софт версии 0.1

1. 

   Ivan_83

   19.06.2017 02:01

   #10270458

   +2

   Так у Игоря она не росла так быстро, он тюнил.
   
   В 2007 году были кореквады, которые вполне могли осилить отдать гиг статики. Да собственно отдать гиг в пару конектов не проблема даже для более слабых систем.
   В то время юзали лайти, он тоже вполне резво отдавал, как минимум жрал меньше.
   
   Что у вас там на практике в sysctl.conf, показывайте уже.
   (покажи мне свой sysctl и я скажу кто ты :) )
   
   Вакуумное объяснение коня в вакууме.
   У вас там раздача чего то, оно через TSO замечательно оффлоадится, как при передаче с юзерспейса а особенно при работе sendfile().
   Более того, если бы полинг был перспективной темой тот же интел сидел бы на попе ровно и нифига не заморачивался с MSI-X, отложенными прерываниями, размерами очередей и прочими свистелками.
   
   Там бывает сильно всё переписывают внутри, кажется TCP одна из немногих горячих зон у нас в ядре.
   
   kqueue() по удачнее и по фичастее, чем epoll(), как следствие под линух костылей больше внутри спрятано.
   
   2 AVX
   В BSD не используется базарный стиль разработки, те архитектура внутри редко меняется настолько значительно чтобы сломать совместимость между модулями/драйверами и требовалось вмешательство.
   Есть геом и нетграф — они вообще имеют стабильный апи, те можно накорабять модуль и он без изменений будет работать и в 7.0 и в 11.1 (те 2008-2017), либо потребуется совсем косметика.
   Отчасти это из за академического подхода, отчасти потому что людей которые пилят каждый день/на постоянной основе не так уж много.
   Если смотреть на ситуацию в целом, то малое количество задействованных людей часто компенсируется более обдуманным подходом:
   — 10 раз обсудить решение потом протестить и закоммитить а не переписывать 100500 как в линухе местами (про skbuf)
   — там где не угнаться, типа писания дров, просто ассимилировать существующее: дрова юзби устройств (вебкамеры, планшеты, тюнеры) от линуха просто запихнуты в webcamd, профит в отладке просто фантастический
   — дрова видюх пока портируются руками с болью, но тоже хотят накорябать прослойку совместимости чтобы свести ручной труд портирования к минимуму
   — линуховые бинарники тоже в большинстве запускаются и работаю (флеш, скайп — из наиболее требовательных и одиозных примеров), через прослойку совместимости/эмуляции. (ни разу не пользовался)
   — ядерные фреймворки типа геом, нетграф и мак — одно удовольствие писать самому модули и пользоваться чужими, низкий порог входа для программиста (относительно даже линуха, не говоря о венде с её мегадровами)
   
   Минусы тоже есть:
   — не так много активного народу, некоторые вещи вообще заброшены потому что всем и так хорошо а на лучшее/фиксы нет времени/людей/желания
   — куча дедов, которым бывает трудно доказать что вот то говно мамонта надо было викинуть из системы лет 10 назад, они всегда отвечают что у них оно активно юзается и вообще они так привыкли. Бывает и что что то новое протащить трудно или объяснить где бага, хотя больше различия языковые и культурные.
   — не всегда в портах всё самых последних версий, иногда нужно и самому взять и обновить чтонить, благо часто достаточно в makefile порта сменить номер версии на актуальный и сделать make makesum а потом make и посмотреть что не работает, выкинуть старые/добавть новые патчи и поделится с сообществом через багтрекер
   — как бы связанно с предыдущим — софт не падает с неба, те разработчки какого нибудь опенцв/вайна/хорга/хфриирдп/глиб/фаерфокс знать ничего не знают про бсд и если хочешь всех плюшек то придётся дописывать работу со специфичными подсистемами самому (типа дописать чтобы понимало звуковую систему осс, с устройствами ввода работало через девд/имеющиеся дрова и тп), а не просто починить сборку. Ну либо сидеть и ждать когда кто то может быть это сделает.
   
   Впрочем всё описанное выше, оно если тебя и накроет то ещё не скоро, тк пока я не поставил фрю на десктоп многие пункты вообще не задевали никак, ибо на сервере редко больше сотни портов, и обычно они более-менее свежие, тк пользователей в кач сервера на порядки больше, чем пользователей на десктопе, да и портов на десктопе менее 500 сложно представить, иначе будет как то слишком аскетично / хардкорно в настройке.

   
   

   1. 

      lieff

      19.06.2017 11:41

      #10270884

      А можете подсказать по возникшим проблемам во фре?
      1) Делал ptrace песочницу. Мне не хватило того что есть в линухе __WNOTHREAD и PTRACE_O_TRACESYSGOOD кажется. Для корректной работы с тредами и сигналами. Нашел systrace, но тоже не понял как корректно работать с тредами.
      
      2) По поводу kqueue, с точки зрения пользователя все здорово и удобно. А вот попытался я драйвер сделать, и у меня вопросы по методам накопления эвентов в ядре. Для epoll все просто, все дескрипторы преаллоцированы, для всего остального можно дропать. А при kqueue, если приложение залипнет на секунду, на две? Сколько и каких эвентов накапливать попадающих в фильтр? Там же переполнение может возникнуть.
      
      3) Пробелма не софсем про фрю, пробовал только на маке — dtrace буфера не гарантированно доставляются, особенно если начать уменьшать размер буфера. Соответственно я не могу на него рассчитывать, если что-то надо посчитать точно, или протрейсить вызовы, особенно если хочется развернуть то что по ссылкам структур, как это делает strace. Вот мой костыль, чтобы хотя бы аргумент execve() достать https://github.com/lieff/mac_exectrace

      
      

      1. 

         Ivan_83

         20.06.2017 13:26

         #10273390

         Я не гуру по всем вопросам, лучше спрашивать в мыллистах.
         
         1. хз
         
         2. Там эвенты по дескрипторам (кроме таймеров и может ещё каких то фильтров), один дескриптор = один эвент на фильтр. Макс размер списка=макс количество дескрипторов, обычно больше 256к лимит дескрипторов никто не задирает, а это совсем крохи памяти. Так что потеряться ничего не должно.
         
         3. То что по ссылкам — должно копироваться при передаче в ядро (copyin) и копироваться из ядра (copyout), вроде как оно пишется в бинарный лог dtrace.
         Вопрос только в том, что родной дампер может это от туда не вытаскивать и тогда нужно писать свой.
         Опять я не экперт по этому механизму, скорее проходил мимо.
         По работе требовалось получить список всех файлов которые использовались при компеляции большого проекта.
         Я сделал так:
         ktrace -f /tmp/build.ktrace -d -i -t cn build-build.sh
         kdump -f /tmp/build.ktrace > /tmp/build.ktext
         parser -i /tmp/build.ktrace -o /tmp/build.log
         
         где, kdump вываливал текстовый лог /tmp/build.ktext который я юзал скорее для отладки своего parser.
         parser — моя фигулина, которая умеет парсить и текстовый лог с предыдущего шага и бинарный. (кажется текстовый я забросил и там есть косяки)
         Структуры меня не интересовали, меня интересовали nami конверсии имён и сисколы им предшествующие.
         Ещё оно отслеживает curdir, форки, наследование окружения и открытых дескрипторов… потому что в nami всё часто уходит от curdir, плюс всякие openat() для которых нужно знать какой путь привязан к дескриптору и прочие плюшки.
         
         2 zuborg
         Касательно TCP congestion control algorithm BBR.
         Проблема совсем не в его отсутствии, ибо она решается за пару дней — сс модули пишутся относительно легко, там микрофреймворк для них есть давно уже.
         Когда я пробовал впилить hybla то наткнулся на то, что оно на моём длинном линке (RTT ~70мс) с потерями работает хуже чем в линухе. Понятное дело я подумал что руки/моск у меня не те. Но тесты показали что тот же htcp и прочие сс алгоритмы с одинаковыми именами и крутилками в линухе работают лучше, сколько бы я не крутил крутилок сисцтл.
         Насколько помню занимался я этим на позапрошлые новогодние праздники на 10.х, вероятно с тех пор могло стать лучше ибо уже 11.1 почти, просто некогда тестировать снова.
         Надо будет посмотреть, может таки починили.
         
         Вместо newreno лучше ставь htcp, ощутимо быстрее.
         В моих условиях с 70+потери hybla работала совсем немного лучше, чем htcp. BBR пока не тестил, набы тоже поглядеть.
         А если невтерпёж — портируй BBR сам, если лицуха позволяет. Если нет — можно в порты положить.
         
         2 acmnu
         Есть ещё DragonFlyBSD, там вроде всё проще — Мэт нормальный мужик.
         Насчёт OpenBSD не в курсе, Тео тот ещё троль в инете, но как это сказывается на приёмке коммитов хз.

         
         

         1. 

            zuborg

            20.06.2017 13:41

            #10273452

            BBR требует ко всему ещё и возможность отсылать пакеты через указанные интервалы, во фре такой функциональности пока нет, а в линуксе для корректной работы BBR надо дополнительно настраивать tc (traffic control)
            
            Да, htcp лучший CC на фре на текущий момент, использую его с самого начала.

            
            

            1. 

               zuborg

               20.06.2017 13:45

               #10273466

               В линуксе htcp работает по другому, думаю, из-за более продвинутого алгоритма управления tcp-буфером. На фиксированном размере буфера скорость должна быть одинаковой.

         
         

         1. 

            lieff

            20.06.2017 14:20

            #10273542

            Проблема в том, что один добавленный эвент в kqueue — на самом деле фильтр, который может генерировать много разных эвентов в сек. Например можно добавить:
            

                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.
            
            Вот надежного решения этой проблемы я и не вижу.

1. 

   acmnu

   19.06.2017 10:28

   #10270734

   -1

   10 раз обсудить решение потом протестить и закоммитить а не переписывать 100500 как в линухе местами (про skbuf)

   У меня три знакомых были коммитерами ещё со времен 4ки. И все оценивают уровень бюрократии и бесполезных "согласований" как заоблачный. Как сказал, бывший начальник: "там все хуже чем в Debian". Хотя по мне куда уж хуже, блин.

   
   

   Думаю именно ваш спицифический подход к разработке отпугивает других разработчиков и уменьшает базу пользователей.