Компания Netflix, в сети доставки контента которой активно используются (https://www.opennet.me/opennews/art.shtml?num=34029) серверы с FreeBSD, совместно с компанией NGINX подготовила (https://lists.freebsd.org/pipermail/svn-src-head/2016-Januar...) новую реализацию системного вызова sendfile (https://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2), предназначенного для организации прямой передачи данных между файловым дескриптором и сокетом. Новая реализация отличается (http://www.slideshare.net/facepalmtarbz2/new-sendfile-in-eng...) значительным увеличением производительности - файл теперь можно направлять в сокет в асинхронном режиме без ожидания завершения передачи данных, копирование производится в фоне с мгновенным возвращением управления.
Разработка работающего в неблокирующем режиме sendfile велась с 2013 года и вчера была принята (https://svnweb.freebsd.org/changeset/base/293439) в основной состав FreeBSD-CURRENT. Код уже протестирован в рабочем кластере Netflix и годен для промышленного применения. Реализация полностью обратно совместима с ранее доступными приложениями и может использоваться в качестве прозрачной замены, не требуя пересборки. Кроме увеличения производительности в новой реализации также добавлены новые флаги, предоставляющие дополнительный контроль над отправкой данных. Например, флаг SF_NOCACHE запрещает кэширование передаваемых данных, а при помощи макроса SF_READAHEAD() можно установить размер буфера упреждающего чтения.URL: https://news.ycombinator.com/item?id=10869311
Новость: http://www.opennet.me/opennews/art.shtml?num=43646
Да начнется компетентное, беспристрастное и многогранное обсуждение каталога Netflix, доступного в России, борьбы с пиратством и торрентов!
Ональный нетфликс чем-то лучше зомбоящика? Нашёл чего обсуждать
Бороться надо не с пиратством а с копирайтом. и бороться до победы!
Не с копирайтом, а с тем, как его применяют копирасты.
пчелы против меда? GPL — это тоже копирайт
> пчелы против меда? GPL — это тоже копирайтПредлОжите другие способы борьбы с копирайтом? Законные? Предположу, что нет.
То есть Вы хотите, чтобы GPL не боролась против Вашего мёда, или предлагаете сторонникам СПО перейти к незaконным методам борьбы?? Пацaны, провoкатор мядовых проприертариев среди нас! Поаплодируем сему "достойному" мужу.
боты всё тупее и тупее.
gpl — это лицензия и она copyleft.
и copyleft не накладывает никаких ограничений?
Накладывает. И эти ограничения работают на благо авторов кода и пользователей, и против жлобов, которые хотят кода на халяву, но не хотят делиться своими доработками.
А копирайт работает только на гоняющихся за сверхприбылями копирастов.
Обоняние, судя по нику, у тебя должно быть хорошим. Почуй разницу.
> Почуй разницу.Я вот чую. GPlv3 - это деградация
Её отвергают и правильно делают.
http://go2.pt/-yVFYc
https://youtu.be/PaKIZ7gJlRUТот же gcc посмотреть - ну жесть же что творится, хорошо что LLVM обороты набирает. Конкуренция хоть будет.
К тому же в последнее время популярно GPL зонд-едишен. Когда у тебя свободная программа сливает о тебе всё во всякие гуглы. Но свобода - да...
> Я вот чую. GPlv3 - это деградацияСторонник тивоизации с плохим обонянием?
> Тот же gcc посмотреть - ну жесть же что творится, хорошо что
> LLVM обороты набирает. Конкуренция хоть будет.При чём тут GPL?
> К тому же в последнее время популярно GPL зонд-едишен. Когда у тебя
> свободная программа сливает о тебе всё во всякие гуглы. Но свобода
> - да...Да, свобода. Возьми исходники и выпили зонды, если тебе так надо, и распространяй чистый продукт. Имеешь право, и как раз из-за соответствующего лицензирования.
А западляны от автора кода, как и этого кода качество, не имею отношения к типу лицензии. Завязывай с демагогией.
А чем принципиально отличаются жлобы не желающие делится наработками от жлобов вообще не занимающихся разработкой софта или разрабатывающих для внутренних нужд? Приписали бы тогда лучше в лицензии: free for non commercial use. Так можно стричь купоны как с компаний разработчиков, так и с прочих, беря деньги за каждую копию ПО. А кто не хочет платить, тот пусть возвращает свои изменения.
> и против жлобов, которые хотят кода на халяву, но не хотят делиться своими доработками.Если только доработками, извольте пользоваться LGPL! Как компромисс GPL/BSD, на мой взгляд, самая именно справедливая лицензия.
> Если только доработками, извольте пользоваться LGPL! Как компромисс GPL/BSD, на мой взгляд,
> самая именно справедливая лицензия.А в чём несправедливость GPL? И какая тут может быть несправедливость?
Если я использую при создания GUI для каталога дисков пару функций для utf16-строк из GPL библиотеки, то я считаю, это несправедливо называть GUI производной от библиотеки для utf16-строк. Это совершенно разные вещи.
А вот, если я воспользовался библиотекой, нашёл ошибку, исправил, и не поделился, хотя от меня не требуют называть мою прогу производной от библиотеки, вот это было бы несправедливо.
а 2-й закон Ньютона? может попробуете пробить головой стену?
этот «наброс вброса» приметивен. попробуйте ещё раз.
Да откуда ж вы такие беретесь?
Лицензия для того и существует, чтобы были ограничения в каком-либо виде. Если вы не хотите вообще никаких ограничений, тогда напуркуа вам вообще лицензия?! нет лицензии - нет ограничений.
Лицензия нужна проверяющим, иначе что они проверять будут.
> нет лицензии - нет ограничений.Вроде, логично, но, оказывается, это не всегда так. Например, в Германии, нет лицензии - вы не можете использовать код вообще. В смысле лично - да (как и с GPL), а если в чём-то публичном, могут засудить, т.к. у вас нет законного основания использовать этот код. Бред, что не существует "public domain", но действительность.
через три года найдут в нём выход за границу буфера, переделают по-уму, производительность пропадёт, а светлая новость в умах останется
> через три года найдут в нём выход за границу буфера, переделают по-уму,
> производительность пропадёт, а светлая новость в умах останетсяМашина времени в подвале? :)
казалось бы, анонимы с опеннета уже похоронили фряху, ан нет
У них фряха только на фронтах, да и сами вложили много в оптимизацию линукса. Очень даже неплохое поведение, как для фанатиков бзд.
> У них фряха только на фронтахУ них вся CDN на фряхе построена: https://openconnect.itp.netflix.com/software/
Ссылка подтверждает коментарий выше.
На бэкенде Linux + Java
> На бэкенде Linux + JavaНа каком бэкэнде? Сударь, Вы вообще понимаете чем занимается Netflix? Они раздают VoD в госудаственных (для США) масштабах, генеря более трети их внутреннего интернет-траффика. Там нет никаких бэкендов/фронтендов, контент раздается конечному получателю сразу со шпинделей бздой с nginx-ом. И там нет места жабе в генерации траффика, только если в интерфейсе юзера, но речь в топике не о нем.
Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было написано по ссылке выше.
> Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было написано по ссылке выше.ЩИТО????? Там этого НЕ написано!
> Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было
> написано по ссылке выше.Наглая ложь не прошла :)
>> На бэкенде Linux + Java
> На каком бэкэнде?Сайт, каталог, описания фильмов, биллинг, личный кабинет и т.д.
CDN - только часть их инфраструктуры.
угу, в линухе man sendfile
> …
> Вызов sendfile() впервые появился в Linux 2.2. Файл заголовков <sys/sendfile.h> появился в glibc 2.1.
> …
> В ядрах Linux до версии 2.6.33, значение out_fd должно указывать на сокет. Начиная с Linux 2.6.33 можно указывать любой файл.и это настолько баян, что например man splice
> splice - подключает данные к каналу/выбирает данные из канала
> …
> Вызов splice() перемещает данные между двумя файловыми дескрипторами не выполняя при этом копирование между адресным пространством пользователя и ядра.всё выше указанное разумеется умеет неблокирующий ввод-вывод.
зыж
х/з, похоронили или нет. может она ещё не родилась?
> всё выше указанное разумеется умеет неблокирующий ввод-вывод.
> зыж
> х/з, похоронили или нет. может она ещё не родилась?Как ни странно, во FreeBSD оно тоже все умеет. Речь идет о принципиально новой реализации sendfile. Хоть слайды то посмотрите, если уж исходники почитать не можете.
> Как ни странно, во FreeBSD оно тоже все умеет.врать то не стыдно? http://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2
> SF_MNOWAIT. Do not wait for some kernel resource to become available, in particular, mbuf and sf_buf. The flag does not make the sendfile() syscall truly non-blocking, since other resources are still allocated in a blocking fashion.ну и остальные (два — SF_NODISKIO и SF_SYNC) флаги.
> Речь идет о принципиально новой реализации sendfile.
Да неужели? ☺
А «всё умеет» — после угона машины времени надо полагать?
> Хоть слайды то посмотрите, если уж исходники почитать не можете.Чем-то ещё своё ЧСВ публично почешете?
> IMPLEMENTATION NOTES
> The FreeBSD implementation of sendfile() is "zero-copy", meaning that it
> has been optimized so that copying of the file data is avoided.
> HISTORY
> The sendfile() system call first appeared in FreeBSD 3.0. This manual
> page first appeared in FreeBSD 3.1.
в неблокирующем режиме только сейчас (см. сабж)
в линухе — с рождения
> в неблокирующем режиме только сейчас (см. сабж)Потому что
> SF_NODISKIO. This flag causes any sendfile() call which would
> block on disk I/O to instead return EBUSY.в манах – вранье?
Или вы решли, что если в бздшных манах честно упоминается:
> The flag does not make the
> sendfile() syscall truly non-blocking, since other resources are
> still allocated in a blocking fashion.то в пингвине дело обстоит совсем-совсем иначе?
Ну так я вас немного разочарую:
http://lxr.free-electrons.com/source/fs/splice.c#L182if (do_wakeup) {
242 smp_mb();
243 if (waitqueue_active(&pipe->wait))
244 wake_up_interruptible_sync(&pipe->wait);
245 kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
246 do_wakeup = 0;
247 }
248
249 pipe->waiting_writers++;
250 pipe_wait(pipe);
251 pipe->waiting_writers--;
Вот о таком в бздшном мане вообще-то и речь.
Потому что block on отлично переводится, как и этот код, которые вы (что очевидно) не понимаете.
Привет эксперту с Opennet от разработчика nginx. Вызов sendfile() на FreeBSD точно также, как и в Linux, с рождения не блокировался на отправке данных в сокет с флагом O_NONBLOCK.Но на обоих системах благополучно блокировался на чтении с диска. Только, в отличии от Linux, на FreeBSD есть ещё флаг SF_NODISKIO, который позволяет в случае отсутствия данных в памяти возвращать управление и далее вычитывать файл другим способом, например с помощью aio_read() или в треде. В Linux подчеркну до сих пор этого нет.
Что было сделано в новой реализации, так это то, что теперь sendfile() в FreeBSD не блокируется не только на сокете, но и на диске, при этом полностью асинхронно читая и отправляя данные даже в том случае, когда те отсутсвуют в кэше страниц.
О том, что в Linux с асинхронным чтением все очень плохо (и плохо по сей день), я более-менее подробно расписал в статье: https://www.nginx.com/blog/thread-pools-boost-performance-9x/
Ну вот зачем Вы "эксперта" обидели. Он ведь работу операционной системы изучает, читая man'ы. Исходников, он, естественно, в глаза не видел, потому как в линуксе самая главная команда "apt-get".
так это всё в манах тоже написано.
> так это всё в манах тоже написано.В БЗДшных – да. В пингвинячьих, как обычно, о блокировке при чтении с диска скромно умолчали.
> Привет эксперту с Opennet от разработчика nginx. Вызов sendfile() на FreeBSD точно также, как и в Linux, с рождения не блокировался на отправке данных в сокет с флагом O_NONBLOCK.Тогда будьте любезны, о великий и ужасный разработчик nginx, приведите новость в соответсвие с текущим состоянием, а не занимайтесь тролячьими вбросами.
Зыж
И судя по пруфам из #42, лично вы не только ужасный, но и лживы.
И маны (и код) говорят именно об этом.
> И судя по пруфам из #42, лично вы не только ужасный, ноПруфы чего? Того, что в бздах к докам традиционно относятся серьезней?
Или того, что вы не в курсе того, что и в пингвине sendfile не совсем "совсем-асинхронный". Я даже не буду говорить за чтение с диска, но вот то, о чем упоминается в бздшном мане
> Do not wait for some kernel resource to become avail‐
> able, in particular, mbuf and sf_buf. The flag does not make the
> sendfile() syscall truly non-blocking, since other resources are
> still allocated in a blocking fashion.имеет место и в ядре пингвина.
зыж
> О том, что в Linux с асинхронным чтением все очень плохо (и плохо по сей день), я более-менее подробно расписал в статье: https://www.nginx.com/blog/thread-pools-boost-performance-9x/ах да, в вашей «статье» почему-то не замечены уже упомянутые выше (не говоря о менее известных):
> Системный вызов splice() впервые появился в Linux 2.6.17; поддержка в glibc добавлена в версии 2.5.
> …
> ЗАМЕЧАНИЯ
> Три системных вызова — splice(), vmsplice(2), and tee(2), предоставляют пользовательским программам полный контроль над произвольным буфером ядра; они реализованы в ядре на базе того же типа буферов, который используется для канала. Эти системные вызовы выполняют следующие задачи:
> splice() перемещает данные из буфера в произвольный файловый дескриптор или наоборот, и из одного буфера вдругой.
> tee(2) «копирует» данные из одного буфера в другой.
> vmsplice(2) «копирует» данные из пользовательского пространства в буфер.не хотелось бы думать что это мозоль от нимба «разработчика nginx».
ззыж
я не разраб nginx, но к разработке например некоторых субд имел отношение. в рамках обсуждения они и более показательны (по всем параметрам кстати), и на ядре linux в подавляющем большинстве дают приличную фору бзде.
так что может в вашей консерватории вам ещё есть что подправить? ну, после нимба?
Уважаемый разработчик Nginx, которым и я пользуюсь (На FreeBSD и Linux) не только указал свое имя, но и привел соответствующие ссылки. Хотелось бы аналогичного ответа:Фамилия, Имя, Отчество, размер пениса, ссылка на статью и на коммиты в ряд СУБД. Пожалуйста.
> позволяет в случае отсутствия данных в памяти возвращать управление и далее вычитывать файл другим способом, например с помощью aio_read()Валентин, пару лет назад на одном из highload-ов был доклад автора erlyvideo о том как они осилили 10Gb. В докладе как главная проблема дальнейшего роста упоминались как раз блокировки чтения с диска. На вопрос не рассматривали ли они переход на фряшный aio как способ решения, докладчик ответил что рассматривали, но отказались поскольку open(), stat() и некоторые другие вызовы все равно остаются блокирующимися и портят всю картину.
Вопрос: как эту проблему решили в nginx/netflix?
Мы в процессе экспериментов перепробовали очень много подходов. Так, например, в результате этих экспериментов во FreeBSD даже появился такой системный вызов как aio_mlock() (см. http://lists.freebsd.org/pipermail/svn-src-all/2013-June/069... ). И если бы проблема блокировки open() и stat() стояла остро, то усилия были бы направлены на её решение тем или иным способом, но нет.Замечу также, что в nginx есть механизм кэша открытых файловых дескрипторов (см. директиву open_file_cache), который для многих кейсов неплохо работает.
В контексте пулов потоков, разумеется, если уж мы оффлоадим read() и sendfile() в отдельный пул потоков, то запихнуть туда в придачу еще open() и stat() было бы интересной оптимизацией. Но это требует некоторого дополнительного количества человеко-часов, которых пока не нашлось. Наибольший интерес тут именно сделать это вместе одним потоком, т.е. сразу открыть файл и начать его читать или отправлять, что несколько ломает существующую логику работы, где эти вызовы бывает довольно сильно разнесены по коду. Выгружать open() и stat() в пул как отдельные задачи не очень интересно, поскольку это добавляет накладных расходов и возможно пессимизирует частый случай, когда эти операции не требуют обращения к диску.
Однако, замечу, что проблема блокировки указанных вызовов пока никак себя не проявила. На тестах с существующей реализацией, где в отдельные потоки выгружаются только read() и sendfile() на линуксе получаются хорошие результаты, заказчик функциональности остался очень доволен и о том, что кто-то на некотором кейсе уперся в open() и stat() я пока не слышал.
> Однако, замечу, что проблема блокировки указанных вызовов пока никак себя не проявила.Понятно. В том докладе озвучивалось что разработчикам доводилось видеть stat() исполняющийся 10 сек на нагруженной системе. Но если у nginx такая проблема отсутствует, то я так понимаю это или следствие другого паттерна использования HDD или следствие багов старых ядер linux (erlyvideo продают бинарники под debian) или просто следствие взаимных блокировок т.к. они на каждый видеопоток для отдачи пускают(пускали?) тред из пула.
Спасибо.
> Привет эксперту с Opennet от разработчика nginx. Вызов sendfile() на FreeBSD точноСпасибо, Валентин, за ваш труд. Приятно осознать, что помимо засилья троллей на этом ресурсе еще можно встретить настоящих профи.
Ан да. "Фряха" жива, как наглядно продемонстрировано еще раз, в больших и раздольных заповедниках типа Netflix, силами случившихся там её энтузиастов, продолжающих её там пилить по недосмотру и снисходительности руководства, часто в подобных заповедниках практически отсутствующего на нижнем и среднем уровне, особенно в тучные годы.
В любых других условиях для массированной отдачи контента берется Linux в одну руку, DPDK в другую, и молоток в третью, и из канала выжимается всё что из него можно выжать, и не в гигабитах в секунду, а в десятках миллионов пакетов с каждого ядра CPU.
> Ан да. "Фряха" жива, как наглядно продемонстрировано еще раз, в больших и
> раздольных заповедниках типа Netflix, силами случившихся там её энтузиастов, продолжающих
> её там пилить по недосмотру и снисходительности руководства, часто в подобных
> заповедниках практически отсутствующего на нижнем и среднем уровне, особенно в тучные
> годы.
> В любых других условиях для массированной отдачи контента берется Linux в одну
> руку, DPDK в другую, и молоток в третью, и из канала
> выжимается всё что из него можно выжать, и не в гигабитах
> в секунду, а в десятках миллионов пакетов с каждого ядра CPU.Камрад, просто бросьте придуряться и посмотрите слайды. Фряшники смогли на реальной задаче и в реальных условиях а не на бенчмарке загнать в насыщение 40Gb сетевуху. После этого ссылки на напильник и DPDK - только попытка сектанта оправдать свою веру.
> смогли на реальной задаче и в реальных условиях а не на бенчмарке загнать в насыщение 40Gb сетевухуCloudFlare это делает постоянно, только не в тепличных условиях dumb отдачи видеоконтента, а в реальных - приёма и анализа трафика значительно более разнообразного и мелкопакетного.
Посмотрите на MoonGen для примера - с DPDK оно на LuaJIT сатурейтит 120 Gbit на хилом ксеоне.
А 20 гигабит - столько erlyvideo раздаёт с одного сервера, в rtmp и с транскодингом, на эрланге, славном своей "быстротой" и обычном линуксе.
> А 20 гигабит - столько erlyvideo раздаёт с одного сервера ... на ... линуксеПравильно. А новость о том что новый sendfile позволил Netflix перейти с 20G на 40G c хоста, т.е на следующую ступеньку на фряхе (это есть в слайдах)
> в rtmp и с транскодингом, на эрланге, славном своей "быстротой"
> в rtmp и с транскодингом, на эрланге, славном своей "быстротой"На 20Gb у них нет никакого транскодинга, во всяко случае полноценного. Там даже mp4 надо очень специально готовить - записывать в один файл несколько вариантов видеодорожки с разными разрешениями причем без интерливинга, иначе будет затыкаться. Это сам автор erlyvideo на одной из конференций говорил, когда жаловался на то какие дебри приходится разгребать пытаясь получить высокий bps
> https://twitter.com/erlyvideo/status/610810756167270403
И где по ссылке искать слово "транскодинг"?
А смысл?
Сам посчитай: DPDK требует чтобы ты с нуля наваял сетевой стёк и ещё потом софт который будет через него раздавать файлы с диска.Ребята аккуратно и не так уж и много поменяли в ядре фри и у них профит: все тонный отлаженного кода работают ещё лучше.
В сравнении с DPDK фре теперь не требуется переключатся из ядра в юзерспейс для отправки, всё в ядре крутится.
Самая лучшая ОСь на свете становится все лучше и лучше.
Годно, нужно - пару дней назад оформил подписку на netflix
Посоветуй что посмотреть из доступного там.
My Little Pony Season 2
Скажу больше:
My Little Pony Season 1
и можно, по желанию
My Little Pony Season 3
А вот не завезли кроме второго сезона ничего в netflix в Этой Стране :) (почему - не знаю)
> А вот не завезли кроме второго сезона ничего в netflix в Этой Стране :) (почему - не знаю)Вот уж, жопа так жопа :-) Нехай эти проприерасты сами 1-й и 3-й сезон в одну глотку смотрят! Мы посмотрим с pirate bay-a и rutracker-a!
Судя по комментариям, никто вообще не знает, что такое sendfile, но все строят их себя "специалистов".
Лично у меня только один вопрос: когда будет MFC ?
Кажись на какой-то из конференций Глеб говорил, что не будет MFC и называл проблемы которые только в 11 были решены.
У мена куча серваков на десятке. Я не готов переводить их на CURRENT :(
Примерно через полгода выйдет первый релиз 11 и продолжение 10.3-RELEASE, где всё это будет "из коробки".
А пока следите за коммитами по этой ссылке:
https://svnweb.freebsd.org/base/stable/10/?sortby=date
> Примерно через полгода выйдет первый релиз 11 и продолжение 10.3-RELEASE, где всё
> это будет "из коробки".
> А пока следите за коммитами по этой ссылке:
> https://svnweb.freebsd.org/base/stable/10/?sortby=dateизя... "не будет MFC" означает ровно то что написано в кавычках. специально для тебя: в 10.х этого не будет
2 Дима: 11-CURRENT это не больно. серьезно:) по крайней мере в отдаче статики гигабитами (видимо то, што Специолизд выше пытался сделать при помощи молотка, линакса и каких-то 4 букав, ага)
До MFC еще далеко. С начало нужно хотя бы что то такое же развесистое как winapi.
> До MFC еще далеко. С начало нужно хотя бы что то
> такое же развесистое как winapi.MergeFromCurrent, не?
А зачем их переводить, данная реализация может быть появится в виде порта...
Это системный вызов. Каким образом можно его оформить в виде порта ?
Здорово, вот только где графики сравнения этой "высокопроизводительной реализации" со старой?
> Здорово, вот только где графики сравнения этой "высокопроизводительной реализации" со
> старой?По ссылкам пройти религия не позволяет? См. слайды 32 и 33. С хоста стали отдавать 35Gbit/s с новым sendfile вместо 20Gbit/s со старым
Я ещё немного наброшу в топку :)Презентации уже больше года. Очевидно, что за год было много сделано. Сейчас рекордные цифры сильно выше, чем 35 Гбит/с, что в презентации. Сейчас рассматриваем возможность перехода с агрегата из двух 40 Гбит/с на одну 100 Гбит/с. Соответственно трафик соответствующий. :) Но помимо нового sendfile сделаны ещё оптимизации в VM и в TCP, без них воспроизвести наши цифры на CURRENT не получится, поэтому я пока и не буду ими хвастать. Но, надеюсь, в скором времени большая часть работы будет в CURRENT.
И вот ещё. Поверх нового sendfile построен SSL_sendfile(), позволяющий ядру слать данные из файла в SSL сокет. Само собой и чтение с диска и шифрование тоже выполняются в фоне.
P.S. Спасибо Валентину, что расставил икспердов и мне надо объяснять про разницу блокирования на сокете и на диске. :)
> И вот ещё. Поверх нового sendfile построен SSL_sendfile(), позволяющий ядру слать данные
> из файла в SSL сокет. Само собой и чтение с диска
> и шифрование тоже выполняются в фоне.Вообще существует ли теоретическое обоснование перевода работ именно в ядро, в смысле, какая разница втом, будет ли работой заниматься поток юзера, переключившийся с ядро, или юзерспайсовый делегирует всё работу специализированому потоку в пространстве ядра, а сам будет ждать уведомлений через поллинг дескрипторов? В солярисе имеется общий принцип: "на каждый чих создаём поток ядра". Это оправдано, так как ОС ориентирована на исполнение на машинах с сотнями CPU. Но непонятно зачем размножение потоков нужно в freebsb которая работает на тазиках с 4-8 CPU. Ну нахватает поток юзерспайсового сервиса запросов не отдачу контента, нагрузит работой по сетевому и блочному IO некоторое количество потоков в ядре, и те точно так же встанут в взаимных локах и зависнут в конкуренции на доступ к разделяемому ресурсу, как заблокировался бы юзерспайcовый поток, на ожидании наполнения кеша address_space в линуксе?
> P.S. Спасибо Валентину, что расставил икспердов и мне надо объяснять про разницу
> блокирования на сокете и на диске.В линуксе бликировка на диске в sendfile происходит только на время ожидания поступления данных с диска при запуске __blk_run_queue, так как заполнение beffer_head данным осуществляется в потоке, сделавшем sendfile. Остальное время поток, сделавший sendfile, не блокируется, а заполняет данными address_space файла, и мапит их в буфера pipe-а и исполняет калбек splice_write дескриптора выходного сокета. Какая разница, какой поток будет блокироваться на время операции чтения данных с диска, поток юзерспайсового сервиса, делающего sendfile, или спецализированного, которому поток юзерпайсового сервиса делегирует эту работу?
В 11-Current по мелочи еще кажись выкинут из ядра kgdb и добавят статическую сборку с модулем zfs.
Нас ждет бесплатная открытая солярка как по мне.
> Нас ждет бесплатная открытая солярка как по мне.Это Вы "её" ждёте. Проприертарский самообман сидит глубоко. //..."десять раз отбей https://www.gnu.org/philosophy/stallmans-law.html лбом об пол"... Охохо, прямо хоть нимб надевай с ними!
Будете приносить сюда анекдоты?)
>> Нас ждет бесплатная открытая солярка как по мне.
> Это Вы "её" ждёте. Проприертарский самообман сидит глубоко.
>
> //..."десять раз отбей https://www.gnu.org/philosophy/stallmans-law.html лбом об пол"...
> Охохо, прямо хоть нимб надевай с ними!И я никого не жду, а уже пользуюсь. И не надо ко мне официально.
Пользуются - практически все, притом давно в продакшне, притом что на линуксе зфс работает гораздо быстрее. И статическая сборка ZFS и SPL поддерживается. Вот только CDDL-лицензию почитай, чтобы понимать во что влип.
> Пользуются - практически все, притом давно в продакшне, притом что на линуксе
> зфс работает гораздо быстрее.и пруфы этого есть?
Может ещё и названия контор с фио внедренцев выложить?
> Может ещё и названия контор с фио внедренцев выложить?названия контор (а тем более фио внедренцев) 100 лет не нужны (и не только мне), но в приличном обществе, рассказывая о том, что "Х в У работает хуже, чем в Й" нужно приводить какие-то аргументы, дабы не выглядеть глупо. Это, как мне кажется, очевидная вещь. От Вас, гражданин, подтверждения Ваших слов мы, понятное дело, не дождемся. Спасибо за подареные при прочтении Вашего сообщения секунды смеха.
> И статическая сборка ZFS и SPL поддерживается.
> Вот только CDDL-лицензию почитай, чтобы понимать во что влип.Бедные пингвинятки в проблемы GPL влипают :'(
Пользуются - практически все, притом давно в продакшне, притом что на линуксе зфс работает гораздо быстрее. И статическая сборка ZFS и SPL поддерживается. Вот только CDDL-лицензию почитай, чтобы понимать во что влип.
> Вообще существует ли теоретическое обоснование перевода работ именно в ядро, в смысле,
> какая разница втом, будет ли работой заниматься поток юзера, переключившийся с ядро, или
> юзерспайсовый делегирует всё работу специализированому потоку в пространстве ядра, а сам
> будет ждать уведомлений через поллинг дескрипторов? В солярисе имеется общий принцип:
> "на каждый чих создаём поток ядра". Это оправдано, так как ОС ориентирована на исполнение
> на машинах с сотнями CPU. Но непонятно зачем размножение потоков нужно в freebsb которая
> работает на тазиках с 4-8 CPU. Ну нахватает поток юзерспайсового сервиса запросов не отдачу
> контента, нагрузит работой по сетевому и блочному IO некоторое количество потоков в ядре,
> и те точно так же встанут в взаимных локах и зависнут в конкуренции на доступ к разделяемому
> ресурсу, как заблокировался бы юзерспайcовый поток, на ожидании наполнения кеша address_space в линуксе?Тут есть два заблуждения. Первое, что вообще для ожидания I/O от устройства обязателен какой-то
поток, который будет блокироваться и ждать. Да, именно так часто и делают. Кому-то кажется,
что так проще развязать блокировку - создать под неё поток, который не жалко заблокировать.
Так же сделана и подсистема aio(4) в FreeBSD, в ней есть ядерный aio daemon. Хоть наша AIO
и намного совершеннее, чем в Linux, но мы решили не завязывать новый sendfile на неё. В новом
sendfile не появляется никаких новых потоков или контекстов. На время, когда диск занят копированием
данных из себя в память, никакого контекста нет, который была бы связан непосредственно с этой
операцией.
Второе заблуждение, это про 4-8 CPU. Ну просто какой-то дичайший стереотип. Мол я дома ставлю
FreeBSD поиграться на всякое старьё, наверное и Netflix так делает?! На самом деле нет. Ну просто
возьмите спеки на то поколение машин, где 4-8 кор и поглядите, сможет ли там PCI пропустить
100 Гбит/с.Что касается ядро-неядро. 15 лет назад была мода всё нести в ядро, мол там быстрее. Теперь появился
netmap и dpdk и в связи с этим новая мода - всё в юзерленд, там быстрее. Ну мебель можно двигать
сколько угодно, а процессор выполняет инструкции с одной скоростью, не важно в каком он сейчас
контексте работает. 15 лет назад смысл переносить функционал в ядро был в том, чтобы избежать
копирования из юзерленд в ядро, а также чтобы уменьшить число переключений контекста, которые
тогда были дорогими. Новая же мода объясняется тем, что ядра обросли функционалом и стали
"подтормаживать на лишних операциях". Поэтому для примитивных задача а ля насрать 50 мегапакетов
в секунду, или же отфильтровать эти же 50 мегапакетов по примитивному критерию, выгоднее стало
писать с нуля сралку или фильтр на dpdk, а операционную систему использовать только для того,
чтобы залогиниться в систему и получить доступ к сетевой карте. Некоторые люди неправильно понимают
этот результат и думают, что если они перенесут весь TCP стек в юзерленд, то он тоже ускорится в
10 раз. Пока успехи на этом поприще достигают только те, кто опять же выполняют очень примитивные
задачи. А как только они доведут свои userland TCP до ума, и по функционалу они будут иметь паритет
с классическими ядерными сокетами, то и производительность выйдет на тот же самый уровень. Ну этот
весь абзац - моё личное мнение. Время покажет, ошибаюсь я или нет.> В линуксе бликировка на диске в sendfile происходит только на время ожидания поступления данных с
> диска при запуске __blk_run_queue, так как заполнение beffer_head данным осуществляется в потоке,
> сделавшем sendfile. Остальное время поток, сделавший sendfile, не блокируется, а заполняет данными
> address_space файла, и мапит их в буфера pipe-а и исполняет калбек splice_write дескриптора выходного
> сокета. Какая разница, какой поток будет блокироваться на время операции чтения данных с диска, поток
> юзерспайсового сервиса, делающего sendfile, или спецализированного, которому поток юзерпайсового
> сервиса делегирует эту работу?У нас никакой не блокируется, в этом и соль.
> Ну мебель можно двигать сколько угодно, а процессор выполняет инструкции с одной скоростью, не важно в каком он сейчас контексте работает.Важно как часто его отрывают от работы для передвигания мебели между ядром и юзерлэндом.
> 15 лет назад смысл переносить функционал в ядро был в том, чтобы избежать копирования из юзерленд в ядро, а также чтобы уменьшить число переключений контекста, которые тогда были дорогими.
Они и сейчас дорогие. И становятся только дороже с "поумнением" процессоров.
> 14,000 cycles after a syscall, code is still not quite running at full speed
> Some of the syscalls cause 40+ TLB evictions. For a chip with a 64-entry d-TLB, that nearly wipes out the TLB. The cache evictions aren’t free, either.
> Новая же мода объясняется тем, что ядра обросли функционалом
> как только они доведут свои userland TCP до ума, и по функционалу они будут иметь паритетс классическими ядерными сокетам
Что не нужно приблизительно никому.
> Компания Netflix, в сети доставки контента которой активно используются серверы с FreeBSDкак же так? а местные аналитики в один голос говорят, что FreeBSD нигде не используется...
> и вчера была принята в основной состав FreeBSD-CURRENT
как же так? а местные аналитики в один голос говорят, что BSD лицензия проприетарная и назад кода не дождаться...
Ну, тогда где ещё? Кроме заповедников типа нетфликса и ихсистемз? Говорят, использовали во всяких опачах, яхах и прочих гуглях.
> Ну, тогда где ещё? Кроме заповедников типа нетфликса и ихсистемз?Берите, просвящайтесь:
https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD
Нашёл чем хвастаться. Список самых махровых проприерастов, кстати, далеко не полный.
Вот видеозапись презентации на русском, что была более года назад.
Тем временем в Linux 4.4, из полезного для Netflix-подобных задач "бери больше, кидай в трубу"> Block-layer I/O polling ("Jens shows that, when polling is enabled, the throughput of an NVM Express device can nearly double")
> LightNVM adds support for Open-Channel SSDs
И другие мелкие улучшения> In this release, and as a result from an effort that started two years ago, the TCP implementation has been refactored to make the TCP listener fast path completely lockless. During tests, a server was able to process 3,500,000 SYN packets per second on one listener and still have available cpu cycles - about 2 to 3 order of magnitude what it was possible before
я не хочу сильно печалить Специалиста, но помимо случившегося буквально часы назад линукс4.4 nvm есть и во freebsd.
p.s. а сколько гигабит с коробки раздаешь лично ты: с линукс, молотком, и теми самыми 4 буквами?;)
p.s. а потешно наблюдать негодование лапчатой школоты^W^Wдевопсиков линаксоедных, ставящих минусы адекватным комментариям по теме :-)))
Остынь, твои 10 гигабит никого не интересуют.
> Остынь, твои 10 гигабит никого не интересуют.твоих-то 10мбит adsl`я сильно больше интересуют, ага)
> Остынь, твои 10 гигабит никого не интересуют.Тем не менее, половина икспердного совета опеннета как всегда прибежало хоронить
> Тем не менее, половина икспердного совета опеннета как всегда прибежало хоронитьСудя по тому, с каким жаром заодно обсудили "My Little Pony" и учитывая то, что зимние каникулы продлили до 10-го января ...
А вот настоящие профессионалы очень гордятся играми в догонялки за линуксом.
> А вот настоящие профессионалы очень гордятся играми в догонялки за линуксом.Не отвлекайся от просмотра "My Little Pony".
> Тем временем в Linux 4.4, из полезного для Netflix-подобных задач "бери больше,
> кидай в трубу"То, что 4.4 "стал лучше" (добавили чего-то там в носу), чем 4.3, не говорит ничего про "лучше чем грузины", fbsd, простите. Тигар прав в этом.
>> Block-layer I/O polling ("Jens shows that, when polling is enabled, the throughput of an NVM Express device can nearly double")
>> LightNVM adds support for Open-Channel SSDsЯ бы ещё спросил, каким местом NVMe к нет-фликсу, но смысл?
ЗЫЖ [Более] lockless сокеты - к н-ф, да, но опять "не в том ядре".
> Я бы ещё спросил, каким местом NVMe к нет-фликсу, но смысл?Не вечно же им раздавать видео с восьмидюймовых флоппи-дисков.
>> Я бы ещё спросил, каким местом NVMe к нет-фликсу, но смысл?
> Не вечно же им раздавать видео с восьмидюймовых флоппи-дисков.какой жЫрный трольчоночег, завидно аж:\
а про "восьмидюймовых флоппи-дисков" у нетфликса можно почитать за авторством, кажется, Scott Long. Большинство местных "могильщиков" столько дисков в жизни не видало, сколько там в каждой коробке стоит.
О том какие "диски" там будут стоять через 5 лет - где можно почитать?
> О том какие "диски" там будут стоять через 5 лет - где
> можно почитать?укради машину времени у дружков по разуму с l.o.r, слетай в +5лет, поведай тут. мне тоже интересно, какие же будут через 5 лет стоять диски (у netflix в т.ч.)
Посмотри что за "диски" используют другие, и узнаешь что будет в нетфликсе через 5 лет.
> Посмотри что за "диски" используют другие, и узнаешь что будет в нетфликсе
> через 5 лет.так покажи же эти "диски", не стесняйся. Можешь даже на примере взрослых дядь с linux, раздающих контент размером гигабайт+ (уже давно не в моде 1.4Гб;)) десятками гигабит с ящика. я в свое время в живую трогал эти дела, там был linux, не было модных аббревиатур типа DPDK (расскажи, пожалуйста, каким он там боком может помочь в плёвом деле - отдаче киношек).
примерно в 2010-12 году я имел некий опыт в подобных штуках. под linux, 100+ коробок c контентом. в каждой по 32Гб памяти и, зеркало из 2 дисков, кажется, 500Гб объема. не мог этот ваш хваленый линукс больше ~600 мегабит (до меня не мог и 300 - дефолтовая инсталляция центос + собраный на каждой коробке (бггг) вручную ngx c flv модулем).
чтобы было понятнее к чему эта байтораздирающая история вся - в 2016 (да и в 2021+) все тот же контент (фильмы, к примеру) будет все на тех же носителях. Объемы не те будут, вот и вся разница. Возможно, это уже будут не hdd которые столь дешевы сейчас по соотношению цена-объем, но как-то в это я не сильно верю - не будут люди (читай корпорации, если тебе так больше нравится) вкладывать гигакилобаксы за объем, который можно получить, затратив четверть-треть-половину от этой суммы.
Суппортер-аникейщик опять пытается составить связный текст из слов, подслушанных в разговорах взрослых дядек. Получается естественно бред сивой кобылы. И даже не понимает обезьяна дрессированная что в конкурентном режиме с двух дисков просто физически больше не получишь.И да лично мне удавалось заполнить 5-гигабитный etherchannel с одного линуксового сервера.
> И даже не понимает обезьяна дрессированная что в конкурентном режиме с двух дисков просто физически больше не получишь.мальчик, после процитированого можешь даже не продолжать высказывать "авторитетное" мнение. а засрать 5гбит хламом мозгов даже твоих хватит, даже на линуксе, даже на 1 коробке. это точно.
в рамках флейма - в 40GigE вливали 8Gbyte/s с линукса
> в рамках флейма - в 40GigE вливали 8Gbyte/s с линуксаЭто понятно. С линукс он такой, он в 40-гигабитную сетевуху может не только 8гигабайт x 8 бит = 64 гигабита влить. Он может и гораздо больше. Применение DPDK вообще дает все over9000 гигабит в секунду. А тонкий тюнинг ведра поняшками и того больше
>> в рамках флейма - в 40GigE вливали 8Gbyte/s с линукса
> Это понятно. С линукс он такой, он в 40-гигабитную сетевуху может не
> только 8гигабайт x 8 бит = 64 гигабита влить. Он может
> и гораздо больше. Применение DPDK вообще дает все over9000 гигабит в
> секунду. А тонкий тюнинг ведра поняшками и того большезачем ты это сделал?
ЗЫЖ интересно, а иксперт принесший DPDK в обсуждение сабжа пропал из комментов т.к. уже понял в чем он был не прав или где?:-)
ЗЗЫЖ интересно, как только родится новость (если родится) о полной поддержке всех фичей dpdk под фрей, будет ли обсуждение в комментах вокруг "зажать код, подстилки, BSDL!!111кококо" или тихонечко промолчат?
> как только родится новость (если родится) о полной поддержке всех фичей dpdk под фрей,Мечтай, под бздами всё так
> зажать код, пoдстилки, BSDL!!111Сам признался.
> Мечтай, под бздами всё такhttp://www.intel.com/content/dam/www/public/us/en/documents/...
Но вы продолжайте лучше оперативно минусовать все упоминания о бздах – на большее вы, очевидно, все равно не способны.
> копирование производится в фоне с мгновенным возвращением управленияЕсли управление возвращается мгновенно, но мгновенно файлы не копируются, а продолжают копироваться и после этого мгновения, то как я узнаю результат копирования после возвращения управления мне? :-)
> как я узнаю результат копирования после возвращения управления мне?Как это сделано в subj-е я не знаю, но в тексте явно упоминался асинхронный режим. Это значит что по завершению должен дергаться коллбек или генерится к-нота или еще как-то формироваться извещение. В этом извещении и должен быть код ошибки.