форумы  помощь  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
Сообщение от opennews on 09-Янв-16, 11:37
Компания Netflix, в сети доставки контента которой активно используются (https://www.opennet.ru/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 Новость: https://www.opennet.ru/opennews/art.shtml?num=43646
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "В состав FreeBSD принята высокопроизводительная реализация s..."	–7 +/–
Сообщение от rob pike on 09-Янв-16, 11:37
Да начнется компетентное, беспристрастное и многогранное обсуждение каталога Netflix, доступного в России, борьбы с пиратством и торрентов!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "В состав FreeBSD принята высокопроизводительная реализация s..."	+14 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 11:39
	Ональный нетфликс чем-то лучше зомбоящика? Нашёл чего обсуждать
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "В состав FreeBSD принята высокопроизводительная реализация s..."	+23 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 12:09
	Бороться надо не с пиратством а с копирайтом. и бороться до победы!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 12:53
	Не с копирайтом, а с тем, как его применяют копирасты.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	21. "В состав FreeBSD принята высокопроизводительная реализация s..."	–4 +/–
	Сообщение от anonchik on 09-Янв-16, 15:30
	пчелы против меда? GPL — это тоже копирайт
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	25. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Andrey Mitrofanov on 09-Янв-16, 16:00
	> пчелы против меда? GPL — это тоже копирайт ПредлОжите другие способы борьбы с копирайтом? Законные? Предположу, что нет. То есть Вы хотите, чтобы GPL не боролась против Вашего мёда, или предлагаете сторонникам СПО перейти к незaконным методам борьбы??    Пацaны, провoкатор мядовых проприертариев среди нас! Поаплодируем сему "достойному" мужу.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	29. "В состав FreeBSD принята высокопроизводительная реализация s..."	+8 +/–
	Сообщение от ананим.orig on 09-Янв-16, 16:21
	боты всё тупее и тупее. gpl — это лицензия и она copyleft.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	32. "В состав FreeBSD принята высокопроизводительная реализация s..."	–7 +/–
	Сообщение от Sabakwaka (ok) on 09-Янв-16, 17:05
	и copyleft не накладывает никаких ограничений?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	37. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Sluggard (ok) on 09-Янв-16, 17:38
	Накладывает. И эти ограничения работают на благо авторов кода и пользователей, и против жлобов, которые хотят кода на халяву, но не хотят делиться своими доработками. А копирайт работает только на гоняющихся за сверхприбылями копирастов. Обоняние, судя по нику, у тебя должно быть хорошим. Почуй разницу.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	45. "В состав FreeBSD принята высокопроизводительная реализация s..."	–9 +/–
	Сообщение от soarin (ok) on 09-Янв-16, 18:28
	> Почуй разницу. Я вот чую. GPlv3 - это деградация Её отвергают и правильно делают. http://go2.pt/-yVFYc https://youtu.be/PaKIZ7gJlRU Тот же gcc посмотреть - ну жесть же что творится, хорошо что LLVM обороты набирает. Конкуренция хоть будет. К тому же в последнее время популярно GPL зонд-едишен. Когда у тебя свободная программа сливает о тебе всё во всякие гуглы. Но свобода - да...
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	46. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Sluggard (ok) on 09-Янв-16, 18:35
	> Я вот чую. GPlv3 - это деградация Сторонник тивоизации с плохим обонянием? > Тот же gcc посмотреть - ну жесть же что творится, хорошо что > LLVM обороты набирает. Конкуренция хоть будет. При чём тут GPL? > К тому же в последнее время популярно GPL зонд-едишен. Когда у тебя > свободная программа сливает о тебе всё во всякие гуглы. Но свобода > - да... Да, свобода. Возьми исходники и выпили зонды, если тебе так надо, и распространяй чистый продукт. Имеешь право, и как раз из-за соответствующего лицензирования. А западляны от автора кода, как и этого кода качество, не имею отношения к типу лицензии. Завязывай с демагогией.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	70. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 10-Янв-16, 06:44
	А чем принципиально отличаются жлобы не желающие делится наработками от жлобов вообще не занимающихся разработкой софта или разрабатывающих для внутренних нужд? Приписали бы тогда лучше в лицензии: free for non commercial use. Так можно стричь купоны как с компаний разработчиков, так и с прочих, беря деньги за каждую копию ПО. А кто не хочет платить, тот пусть возвращает свои изменения.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	85. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от Андрей (??) on 10-Янв-16, 16:31
	> и против жлобов, которые хотят кода на халяву, но не хотят делиться своими доработками. Если только доработками, извольте пользоваться LGPL! Как компромисс GPL/BSD, на мой взгляд, самая именно справедливая лицензия.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	86. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Sluggard (ok) on 10-Янв-16, 16:34
	> Если только доработками, извольте пользоваться LGPL! Как компромисс GPL/BSD, на мой взгляд, > самая именно справедливая лицензия. А в чём несправедливость GPL? И какая тут может быть несправедливость?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	87. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Андрей (??) on 10-Янв-16, 17:41
	Если я использую при создания GUI для каталога дисков пару функций для utf16-строк из GPL библиотеки, то я считаю, это несправедливо называть GUI производной от библиотеки для utf16-строк. Это совершенно разные вещи. А вот, если я воспользовался библиотекой, нашёл ошибку, исправил, и не поделился, хотя от меня не требуют называть мою прогу производной от библиотеки, вот это было бы несправедливо.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	38. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от ананим.orig on 09-Янв-16, 17:45
	а 2-й закон Ньютона? может попробуете пробить головой стену? этот «наброс вброса» приметивен. попробуйте ещё раз.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	44. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от кверти (ok) on 09-Янв-16, 18:24
	Да откуда ж вы такие беретесь? Лицензия для того и существует, чтобы были ограничения в каком-либо виде. Если вы не хотите вообще никаких ограничений, тогда напуркуа вам вообще лицензия?! нет лицензии - нет ограничений.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	63. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от ПолковникВасечкин on 10-Янв-16, 01:23
	Лицензия нужна проверяющим, иначе что они проверять будут.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	84. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Андрей (??) on 10-Янв-16, 16:29
	> нет лицензии - нет ограничений. Вроде, логично, но, оказывается, это не всегда так. Например, в Германии, нет лицензии - вы не можете использовать код вообще. В смысле лично - да (как и с GPL), а если в чём-то публичном, могут засудить, т.к. у вас нет законного основания использовать этот код. Бред, что не существует "public domain", но действительность.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

2. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
Сообщение от Аноним (??) on 09-Янв-16, 11:37
через три года найдут в нём выход за границу буфера, переделают по-уму, производительность пропадёт, а светлая новость в умах останется
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	161. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от XoRe (ok) on 13-Окт-16, 00:54
	> через три года найдут в нём выход за границу буфера, переделают по-уму, > производительность пропадёт, а светлая новость в умах останется Машина времени в подвале? :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
Сообщение от Аноним (??) on 09-Янв-16, 12:05
казалось бы, анонимы с опеннета уже похоронили фряху, ан нет
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "В состав FreeBSD принята высокопроизводительная реализация s..."	–4 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 14:15
	У них фряха только на фронтах, да и сами вложили много в оптимизацию линукса. Очень даже неплохое поведение, как для фанатиков бзд.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	24. "В состав FreeBSD принята высокопроизводительная реализация s..."	+5 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 15:58
	> У них фряха только на фронтах У них вся CDN на фряхе построена: https://openconnect.itp.netflix.com/software/
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	52. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 19:53
	Ссылка подтверждает коментарий выше.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	55. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 20:15
	На бэкенде Linux + Java
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	58. "В состав FreeBSD принята высокопроизводительная реализация s..."	+4 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 22:56
	> На бэкенде Linux + Java На каком бэкэнде? Сударь, Вы вообще понимаете чем занимается Netflix? Они раздают VoD в госудаственных (для США) масштабах, генеря более трети их внутреннего интернет-траффика. Там нет никаких бэкендов/фронтендов, контент раздается конечному получателю сразу со шпинделей бздой с nginx-ом. И там нет места жабе в генерации траффика, только если в интерфейсе юзера, но речь в топике не о нем.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	71. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 10:59
	Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было написано по ссылке выше.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	75. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 13:04
	> Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было написано по ссылке выше. ЩИТО????? Там этого НЕ написано!
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	118. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 20:06
	> Под бэкэндом имеется в виду CDN-origin. И там живёт пингвин, как было > написано по ссылке выше. Наглая ложь не прошла :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	162. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от XoRe (ok) on 13-Окт-16, 00:57
	>> На бэкенде Linux + Java > На каком бэкэнде? Сайт, каталог, описания фильмов, биллинг, личный кабинет и т.д. CDN - только часть их инфраструктуры.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	30. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от ананим.orig on 09-Янв-16, 16:44
	угу, в линухе 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()  перемещает  данные  между  двумя  файловыми  дескрипторами  не выполняя при этом копирование между адресным пространством пользователя и ядра. всё выше указанное разумеется умеет неблокирующий ввод-вывод. зыж х/з, похоронили или нет. может она ещё не родилась?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	31. "В состав FreeBSD принята высокопроизводительная реализация s..."	+7 +/–
	Сообщение от Dmitry (??) on 09-Янв-16, 17:01
	> всё выше указанное разумеется умеет неблокирующий ввод-вывод. > зыж > х/з, похоронили или нет. может она ещё не родилась? Как ни странно, во FreeBSD оно тоже все умеет. Речь идет о принципиально новой реализации sendfile. Хоть слайды то посмотрите, если уж исходники почитать не можете.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	42. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
	Сообщение от ананим.orig on 09-Янв-16, 18:09
	> Как ни странно, во 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. Да неужели? ☺ А «всё умеет» — после угона машины времени надо полагать? > Хоть слайды то посмотрите, если уж исходники почитать не можете. Чем-то ещё своё ЧСВ публично почешете?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	39. "В состав FreeBSD принята высокопроизводительная реализация s..."	+5 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 17:51
	> 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.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	43. "В состав FreeBSD принята высокопроизводительная реализация s..."	–5 +/–
	Сообщение от ананим.orig on 09-Янв-16, 18:18
	в неблокирующем режиме только сейчас (см. сабж) в линухе — с рождения
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	89. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 18:53
	> в неблокирующем режиме только сейчас (см. сабж) Потому что > 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#L182 if (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--; Вот о таком в бздшном мане вообще-то и речь.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	103. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от ананим.orig on 11-Янв-16, 07:19
	Потому что block on отлично переводится, как и этот код, которые вы (что очевидно) не понимаете.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	62. "В состав FreeBSD принята высокопроизводительная реализация s..."	+20 +/–
	Сообщение от Valentin V. Bartenev on 10-Янв-16, 01:08
	Привет эксперту с 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/
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	65. "В состав FreeBSD принята высокопроизводительная реализация s..."	+5 +/–
	Сообщение от Dmitry (??) on 10-Янв-16, 01:31
	Ну вот зачем Вы "эксперта" обидели. Он ведь работу операционной системы изучает, читая man'ы. Исходников, он, естественно, в глаза не видел, потому как в линуксе самая главная команда "apt-get".
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	66. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 10-Янв-16, 01:55
	так это всё в манах тоже написано.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	67. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 02:20
	> так это всё в манах тоже написано. В БЗДшных – да. В пингвинячьих, как обычно, о блокировке при чтении с диска скромно умолчали.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	68. "В состав FreeBSD принята высокопроизводительная реализация s..."	–7 +/–
	Сообщение от ананим.orig on 10-Янв-16, 04:04
	> Привет эксперту с Opennet от разработчика nginx. Вызов sendfile() на FreeBSD точно также, как и в Linux, с рождения не блокировался на отправке данных в сокет с флагом O_NONBLOCK. Тогда будьте любезны, о великий и ужасный разработчик nginx, приведите новость в соответсвие с текущим состоянием, а не занимайтесь тролячьими вбросами. Зыж И судя по пруфам из #42, лично вы не только ужасный, но и лживы. И маны (и код) говорят именно об этом.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	90. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 19:02
	> И судя по пруфам из #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. имеет место и в ядре пингвина.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	69. "В состав FreeBSD принята высокопроизводительная реализация s..."	–5 +/–
	Сообщение от ананим.orig on 10-Янв-16, 04:58
	зыж > О том, что в 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 в подавляющем большинстве дают приличную фору бзде. так что может в вашей консерватории вам ещё есть что подправить? ну, после нимба?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	76. "В состав FreeBSD принята высокопроизводительная реализация s..."	+8 +/–
	Сообщение от ы on 10-Янв-16, 13:27
	Уважаемый разработчик Nginx, которым и я пользуюсь (На FreeBSD и Linux) не только указал свое имя, но и привел соответствующие ссылки. Хотелось бы аналогичного ответа: Фамилия, Имя, Отчество, размер пениса, ссылка на статью и на коммиты в ряд СУБД. Пожалуйста.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	80. "В состав FreeBSD принята высокопроизводительная реализация s..."	+7 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 15:46
	> позволяет в случае отсутствия данных в памяти возвращать управление и далее вычитывать файл другим способом, например с помощью aio_read() Валентин, пару лет назад на одном из highload-ов был доклад автора erlyvideo о том как они осилили 10Gb. В докладе как главная проблема дальнейшего роста упоминались как раз блокировки чтения с диска. На вопрос не рассматривали ли они переход на фряшный aio как способ решения, докладчик ответил что рассматривали, но отказались поскольку open(), stat() и некоторые другие вызовы все равно остаются блокирующимися и портят всю картину. Вопрос: как эту проблему решили в nginx/netflix?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	123. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Valentin V. Bartenev on 11-Янв-16, 23:18
	Мы в процессе экспериментов перепробовали очень много подходов. Так, например, в результате этих экспериментов во 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() я пока не слышал.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	124. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 12-Янв-16, 01:35
	> Однако, замечу, что проблема блокировки указанных вызовов пока никак себя не проявила. Понятно. В том докладе озвучивалось что разработчикам доводилось видеть stat() исполняющийся 10 сек на нагруженной системе. Но если у nginx такая проблема отсутствует, то я так понимаю это или следствие другого паттерна использования HDD или следствие багов старых ядер linux (erlyvideo продают бинарники под debian) или просто следствие взаимных блокировок т.к. они на каждый видеопоток для отдачи пускают(пускали?) тред из пула. Спасибо.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	159. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от AdVv (ok) on 14-Янв-16, 22:50
	> Привет эксперту с Opennet от разработчика nginx. Вызов sendfile() на FreeBSD точно Спасибо, Валентин, за ваш труд. Приятно осознать, что помимо засилья троллей на этом ресурсе еще можно встретить настоящих профи.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	41. "В состав FreeBSD принята высокопроизводительная реализация s..."	–5 +/–
	Сообщение от rob pike on 09-Янв-16, 18:02
	Ан да. "Фряха" жива, как наглядно продемонстрировано еще раз, в больших и раздольных заповедниках типа Netflix, силами случившихся там её энтузиастов, продолжающих её там пилить по недосмотру и снисходительности руководства, часто в подобных заповедниках практически отсутствующего на нижнем и среднем уровне, особенно в тучные годы. В любых других условиях для массированной отдачи контента берется Linux в одну руку, DPDK в другую, и молоток в третью, и из канала выжимается всё что из него можно выжать, и не в гигабитах в секунду, а в десятках миллионов пакетов с каждого ядра CPU.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	59. "В состав FreeBSD принята высокопроизводительная реализация s..."	+6 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 23:08
	> Ан да. "Фряха" жива, как наглядно продемонстрировано еще раз, в больших и > раздольных заповедниках типа Netflix, силами случившихся там её энтузиастов, продолжающих > её там пилить по недосмотру и снисходительности руководства, часто в подобных > заповедниках практически отсутствующего на нижнем и среднем уровне, особенно в тучные > годы. > В любых других условиях для массированной отдачи контента берется Linux в одну > руку, DPDK в другую, и молоток в третью, и из канала > выжимается всё что из него можно выжать, и не в гигабитах > в секунду, а в десятках миллионов пакетов с каждого ядра CPU. Камрад, просто бросьте придуряться и посмотрите слайды. Фряшники смогли на реальной задаче и в реальных условиях а не на бенчмарке загнать в насыщение 40Gb сетевуху. После этого ссылки на напильник и DPDK - только попытка сектанта оправдать свою веру.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	74. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
	Сообщение от rob pike on 10-Янв-16, 12:34
	> смогли на реальной задаче и в реальных условиях а не на бенчмарке загнать в насыщение 40Gb сетевуху CloudFlare это делает постоянно, только не в тепличных условиях dumb отдачи видеоконтента, а в реальных - приёма и анализа трафика значительно более разнообразного и мелкопакетного. Посмотрите на MoonGen для примера - с DPDK оно на LuaJIT сатурейтит 120 Gbit на хилом ксеоне. А 20 гигабит - столько erlyvideo раздаёт с одного сервера, в rtmp и с транскодингом, на  эрланге, славном своей "быстротой" и обычном линуксе.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	79. "В состав FreeBSD принята высокопроизводительная реализация s..."	+6 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 15:25
	> А 20 гигабит - столько erlyvideo раздаёт с одного сервера ... на ... линуксе Правильно. А новость о том что новый sendfile позволил Netflix перейти с 20G на 40G c хоста, т.е на следующую ступеньку на фряхе (это есть в слайдах)
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	81. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от rob pike on 10-Янв-16, 15:49
	> в rtmp и с транскодингом, на  эрланге, славном своей "быстротой"
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	82. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Аноним (??) on 10-Янв-16, 16:13
	> в rtmp и с транскодингом, на  эрланге, славном своей "быстротой" На 20Gb у них нет никакого транскодинга, во всяко случае полноценного. Там даже mp4 надо очень специально готовить - записывать в один файл несколько вариантов видеодорожки с разными разрешениями причем без интерливинга, иначе будет затыкаться. Это сам автор erlyvideo на одной из конференций говорил, когда жаловался на то какие дебри приходится разгребать пытаясь получить высокий bps
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	99. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
	Сообщение от rob pike on 11-Янв-16, 03:37
	> https://twitter.com/erlyvideo/status/610810756167270403
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	105. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 10:58
	И где по ссылке искать слово "транскодинг"?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	64. "В состав FreeBSD принята высокопроизводительная реализация s..."	+5 +/–
	Сообщение от Ivan_83 (ok) on 10-Янв-16, 01:26
	А смысл? Сам посчитай: DPDK требует чтобы ты с нуля наваял сетевой стёк и ещё потом софт который будет через него раздавать файлы с диска. Ребята аккуратно и не так уж и много поменяли в ядре фри и у них профит: все тонный отлаженного кода работают ещё лучше. В сравнении с DPDK фре теперь не требуется переключатся из ядра в юзерспейс для отправки, всё в ядре крутится.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

6. "В состав FreeBSD принята высокопроизводительная реализация s..."	+4 +/–
Сообщение от Аноним (??) on 09-Янв-16, 12:27
Самая лучшая ОСь на свете становится все лучше и лучше.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
Сообщение от soarin (ok) on 09-Янв-16, 12:44
Годно, нужно - пару дней назад оформил подписку на netflix
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Наркоман on 09-Янв-16, 14:04
	Посоветуй что посмотреть из доступного там.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "В состав FreeBSD принята высокопроизводительная реализация s..."	+8 +/–
	Сообщение от soarin (ok) on 09-Янв-16, 14:21
	My Little Pony Season 2
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	28. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 16:17
	Скажу больше: My Little Pony Season 1 и можно, по желанию My Little Pony Season 3
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	36. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от soarin (ok) on 09-Янв-16, 17:30
	А вот не завезли кроме второго сезона ничего в netflix в Этой Стране :) (почему - не знаю)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	61. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 10-Янв-16, 00:25
	> А вот не завезли кроме второго сезона ничего в netflix в Этой Стране :) (почему - не знаю) Вот уж, жопа так жопа :-) Нехай эти проприерасты сами 1-й и 3-й сезон в одну глотку смотрят! Мы посмотрим с pirate bay-a и rutracker-a!
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

16. "В состав FreeBSD принята высокопроизводительная реализация s..."	+4 +/–
Сообщение от Dmitry (??) on 09-Янв-16, 14:31
Судя по комментариям, никто вообще не знает, что такое sendfile, но все строят их себя "специалистов". Лично у меня только один вопрос: когда будет MFC ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от fidaj (ok) on 09-Янв-16, 14:37
	Кажись на какой-то из конференций Глеб говорил, что не будет MFC и называл проблемы которые только в 11 были решены.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Dmitry (??) on 09-Янв-16, 14:43
	У мена куча серваков на десятке. Я не готов переводить их на CURRENT :(
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	23. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от iZEN (ok) on 09-Янв-16, 15:49
	Примерно через полгода выйдет первый релиз 11 и продолжение 10.3-RELEASE, где всё это будет "из коробки". А пока следите за коммитами по этой ссылке: https://svnweb.freebsd.org/base/stable/10/?sortby=date
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	73. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от тигар (ok) on 10-Янв-16, 11:33
	> Примерно через полгода выйдет первый релиз 11 и продолжение 10.3-RELEASE, где всё > это будет "из коробки". > А пока следите за коммитами по этой ссылке: > https://svnweb.freebsd.org/base/stable/10/?sortby=date изя... "не будет MFC" означает ровно то что написано в кавычках. специально для тебя: в 10.х этого не будет 2 Дима: 11-CURRENT это не больно. серьезно:) по крайней мере в отдаче статики гигабитами (видимо то, што Специолизд выше пытался сделать при помощи молотка, линакса и каких-то 4 букав, ага)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	47. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 09-Янв-16, 19:07
	До MFC  еще далеко. С начало нужно хотя бы что то такое же развесистое как winapi.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	57. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 09-Янв-16, 21:52
	> До MFC  еще далеко. С начало нужно хотя бы что то > такое же развесистое как winapi. MergeFromCurrent, не?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

19. "В состав FreeBSD принята высокопроизводительная реализация s..."	–4 +/–
Сообщение от Сергей (??) on 09-Янв-16, 15:08
А зачем их переводить, данная реализация может быть появится в виде порта...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "В состав FreeBSD принята высокопроизводительная реализация s..."	+5 +/–
	Сообщение от Dmitry (??) on 09-Янв-16, 15:16
	Это системный вызов. Каким образом можно его оформить в виде порта ?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
Сообщение от mozgoprav (ok) on 09-Янв-16, 15:45
Здорово, вот только где графики сравнения этой "высокопроизводительной реализации" со старой?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 09-Янв-16, 16:09
	> Здорово, вот только где графики сравнения этой "высокопроизводительной реализации" со > старой? По ссылкам пройти религия не позволяет? См. слайды 32 и 33. С хоста стали отдавать 35Gbit/s с новым sendfile вместо 20Gbit/s со старым
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	91. "В состав FreeBSD принята высокопроизводительная реализация s..."	+7 +/–
	Сообщение от glebius (ok) on 10-Янв-16, 23:44
	Я ещё немного наброшу в топку :) Презентации уже больше года. Очевидно, что за год было много сделано. Сейчас рекордные цифры сильно выше, чем 35 Гбит/с, что в презентации. Сейчас рассматриваем возможность перехода с агрегата из двух 40 Гбит/с на одну 100 Гбит/с. Соответственно трафик соответствующий. :) Но помимо нового sendfile сделаны ещё оптимизации в VM и в TCP, без них воспроизвести наши цифры на CURRENT не получится, поэтому я пока и не буду ими хвастать. Но, надеюсь, в скором времени большая часть работы будет в CURRENT. И вот ещё. Поверх нового sendfile построен SSL_sendfile(), позволяющий ядру слать данные из файла в SSL сокет. Само собой и чтение с диска и шифрование тоже выполняются в фоне. P.S. Спасибо Валентину, что расставил икспердов и мне надо объяснять про разницу блокирования на сокете и на диске. :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	111. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
	Сообщение от metallica (ok) on 11-Янв-16, 13:23
	> И вот ещё. Поверх нового 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, или спецализированного, которому поток юзерпайсового сервиса делегирует эту работу?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	117. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 19:54
	В 11-Current по мелочи еще кажись выкинут из ядра kgdb и добавят статическую сборку с модулем zfs. Нас ждет бесплатная открытая солярка как по мне.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Andrey Mitrofanov on 11-Янв-16, 20:50
	> Нас ждет бесплатная открытая солярка как по мне. Это Вы "её" ждёте. Проприертарский самообман сидит глубоко.                 //..."десять раз отбей https://www.gnu.org/philosophy/stallmans-law.html лбом об пол"... Охохо, прямо хоть нимб надевай с ними!
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	121. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 11-Янв-16, 21:00
	Будете приносить сюда анекдоты?)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	122. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 11-Янв-16, 21:05
	>> Нас ждет бесплатная открытая солярка как по мне. > Это Вы "её" ждёте. Проприертарский самообман сидит глубоко.     >             >  //..."десять раз отбей https://www.gnu.org/philosophy/stallmans-law.html лбом об пол"... > Охохо, прямо хоть нимб надевай с ними! И я никого не жду, а уже пользуюсь. И не надо ко мне официально.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	138. "В состав FreeBSD принята высокопроизводительная реализация s..."	–3 +/–
	Сообщение от Аноним (??) on 12-Янв-16, 13:13
	Пользуются - практически все, притом давно в продакшне, притом что на линуксе зфс работает гораздо быстрее. И статическая сборка ZFS и SPL поддерживается. Вот только CDDL-лицензию почитай, чтобы понимать во что влип.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	144. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от тигар (ok) on 12-Янв-16, 13:56
	> Пользуются - практически все, притом давно в продакшне, притом что на линуксе > зфс работает гораздо быстрее. и пруфы этого есть?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	146. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 12-Янв-16, 15:42
	Может ещё и названия контор с фио внедренцев выложить?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	150. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
	Сообщение от тигар (ok) on 12-Янв-16, 15:58
	> Может ещё и названия контор с фио внедренцев выложить? названия контор (а тем более фио внедренцев) 100 лет не нужны (и не только мне), но в приличном обществе, рассказывая о том, что "Х в У работает хуже, чем в Й" нужно приводить какие-то аргументы, дабы не выглядеть глупо. Это, как мне кажется, очевидная вещь. От Вас, гражданин, подтверждения Ваших слов мы, понятное дело, не дождемся. Спасибо за подареные при прочтении Вашего сообщения секунды смеха.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	147. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 12-Янв-16, 15:45
	> И статическая сборка ZFS и SPL поддерживается. > Вот только CDDL-лицензию почитай, чтобы понимать во что влип. Бедные пингвинятки в проблемы GPL влипают :'(
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	139. "В состав FreeBSD принята высокопроизводительная реализация s..."	–4 +/–
	Сообщение от Аноним (??) on 12-Янв-16, 13:21
	Пользуются - практически все, притом давно в продакшне, притом что на линуксе зфс работает гораздо быстрее. И статическая сборка ZFS и SPL поддерживается. Вот только CDDL-лицензию почитай, чтобы понимать во что влип.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	125. "В состав FreeBSD принята высокопроизводительная реализация s..."	+9 +/–
	Сообщение от glebius (ok) on 12-Янв-16, 01:37
	> Вообще существует ли теоретическое обоснование перевода работ именно в ядро, в смысле, > какая разница втом, будет ли работой заниматься поток юзера, переключившийся с ядро, или > юзерспайсовый делегирует всё работу специализированому потоку в пространстве ядра, а сам > будет ждать уведомлений через поллинг дескрипторов? В солярисе  имеется общий принцип: > "на каждый чих создаём поток ядра". Это оправдано, так как ОС ориентирована на исполнение > на машинах с сотнями 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, или спецализированного, которому поток юзерпайсового > сервиса делегирует эту работу? У нас никакой не блокируется, в этом и соль.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	160. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от rob pike on 16-Янв-16, 14:01
	> Ну мебель можно двигать сколько угодно, а процессор выполняет инструкции с одной скоростью, не важно в каком он сейчас контексте работает. Важно как часто его отрывают от работы для передвигания мебели между ядром и юзерлэндом. > 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 до ума, и по функционалу они будут иметь паритет с классическими ядерными сокетам Что не нужно приблизительно никому.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

78. "В состав FreeBSD принята высокопроизводительная реализация s..."	+7 +/–
Сообщение от Клыкастый (ok) on 10-Янв-16, 14:31
> Компания Netflix, в сети доставки контента которой активно используются серверы с FreeBSD как же так? а местные аналитики в один голос говорят, что FreeBSD нигде не используется... > и вчера была принята в основной состав FreeBSD-CURRENT как же так? а местные аналитики в один голос говорят, что BSD лицензия проприетарная и назад кода не дождаться...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	95. "В состав FreeBSD принята высокопроизводительная реализация s..."	–4 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 00:30
	Ну, тогда где ещё? Кроме заповедников типа нетфликса и ихсистемз? Говорят, использовали во всяких опачах, яхах и прочих гуглях.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	97. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 11-Янв-16, 02:22
	> Ну, тогда где ещё? Кроме заповедников типа нетфликса и ихсистемз? Берите, просвящайтесь: https://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	140. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
	Сообщение от Аноним (??) on 12-Янв-16, 13:22
	Нашёл чем хвастаться. Список самых махровых проприерастов, кстати, далеко не полный.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

92. "В состав FreeBSD принята высокопроизводительная реализация s..."	+3 +/–
Сообщение от glebius (ok) on 10-Янв-16, 23:45
Вот видеозапись презентации на русском, что была более года назад. https://events.yandex.ru/lib/talks/2682/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

100. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
Сообщение от rob pike on 11-Янв-16, 03:51
Тем временем в 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	101. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от rob pike on 11-Янв-16, 03:55
	И другие мелкие улучшения > 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
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	104. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от тигар (ok) on 11-Янв-16, 09:26
	я не хочу сильно печалить Специалиста, но помимо случившегося буквально часы назад линукс4.4 nvm есть и во freebsd. p.s. а сколько гигабит с коробки раздаешь лично ты: с линукс, молотком, и теми самыми 4 буквами?;) p.s. а потешно наблюдать негодование лапчатой школоты^W^Wдевопсиков линаксоедных, ставящих минусы адекватным комментариям по теме :-)))
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	107. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 11-Янв-16, 11:01
	Остынь, твои 10 гигабит никого не интересуют.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	109. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от имя on 11-Янв-16, 11:18
	> Остынь, твои 10 гигабит никого не интересуют. твоих-то 10мбит adsl`я сильно больше интересуют, ага)
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	110. "В состав FreeBSD принята высокопроизводительная реализация s..."	+2 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 11:18
	> Остынь, твои 10 гигабит никого не интересуют. Тем не менее, половина икспердного совета опеннета как всегда прибежало хоронить
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	113. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Аноним (??) on 11-Янв-16, 15:46
	> Тем не менее, половина икспердного совета опеннета как всегда прибежало хоронить Судя по тому, с каким жаром заодно обсудили "My Little Pony" и учитывая то, что зимние каникулы продлили до 10-го января ...
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	141. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Аноним (??) on 12-Янв-16, 13:28
	А вот настоящие профессионалы очень гордятся играми в догонялки за линуксом.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	145. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Dmitry (??) on 12-Янв-16, 15:03
	> А вот настоящие профессионалы очень гордятся играми в догонялки за линуксом. Не отвлекайся от просмотра "My Little Pony".
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	108. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Andrey Mitrofanov on 11-Янв-16, 11:08
	> Тем временем в 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 сокеты - к н-ф, да, но опять "не в том ядре".
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	112. "В состав FreeBSD принята высокопроизводительная реализация s..."	–2 +/–
	Сообщение от rob pike on 11-Янв-16, 15:29
	> Я бы ещё спросил, каким местом NVMe к нет-фликсу, но смысл? Не вечно же им раздавать видео с восьмидюймовых флоппи-дисков.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	115. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от имя on 11-Янв-16, 17:18
	>> Я бы ещё спросил, каким местом NVMe к нет-фликсу, но смысл? > Не вечно же им раздавать видео с восьмидюймовых флоппи-дисков. какой жЫрный трольчоночег, завидно аж:\ а про "восьмидюймовых флоппи-дисков" у нетфликса можно почитать за авторством, кажется, Scott Long. Большинство местных "могильщиков" столько дисков в жизни не видало, сколько там в каждой коробке стоит.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	119. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от rob pike on 11-Янв-16, 20:43
	О том какие "диски" там будут стоять через 5 лет - где можно почитать?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	132. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от тигар (ok) on 12-Янв-16, 10:54
	> О том какие "диски" там будут стоять через 5 лет - где > можно почитать? укради машину времени у дружков по разуму с l.o.r, слетай в +5лет, поведай тут. мне тоже интересно, какие же будут через 5 лет стоять диски (у netflix в т.ч.)
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	149. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 12-Янв-16, 15:50
	Посмотри что за "диски" используют другие, и узнаешь что будет в нетфликсе через 5 лет.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	151. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от тигар (ok) on 12-Янв-16, 16:26
	> Посмотри что за "диски" используют другие, и узнаешь что будет в нетфликсе > через 5 лет. так покажи же эти "диски", не стесняйся. Можешь даже на примере взрослых дядь с linux, раздающих контент размером гигабайт+ (уже давно не в моде 1.4Гб;)) десятками гигабит с ящика. я в свое время в живую трогал эти дела, там был linux, не было модных аббревиатур типа DPDK (расскажи, пожалуйста, каким он там боком может помочь в плёвом деле - отдаче киношек). примерно в 2010-12 году я имел некий опыт в подобных штуках. под linux, 100+ коробок c контентом. в каждой по 32Гб памяти и, зеркало из 2 дисков, кажется, 500Гб объема. не мог этот ваш хваленый линукс больше ~600 мегабит (до меня не мог и 300 - дефолтовая инсталляция центос + собраный на каждой коробке (бггг) вручную ngx c flv модулем). чтобы было понятнее к чему эта байтораздирающая история вся - в 2016 (да и в 2021+) все тот же контент (фильмы, к примеру) будет все на тех же носителях. Объемы не те будут, вот и вся разница. Возможно, это уже будут не hdd которые столь дешевы сейчас по соотношению цена-объем, но как-то в это я не сильно верю - не будут люди (читай корпорации, если тебе так больше нравится) вкладывать гигакилобаксы за объем, который можно получить, затратив четверть-треть-половину от этой суммы.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	152. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от Аноним (??) on 13-Янв-16, 10:57
	Суппортер-аникейщик опять пытается составить связный текст из слов, подслушанных в разговорах взрослых дядек. Получается естественно бред сивой кобылы. И даже не понимает обезьяна дрессированная что в конкурентном режиме с двух дисков просто физически больше не получишь. И да лично мне удавалось заполнить 5-гигабитный etherchannel с одного линуксового сервера.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	153. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
	Сообщение от тигар (ok) on 13-Янв-16, 11:18
	> И даже не понимает обезьяна дрессированная что в конкурентном режиме с двух дисков просто физически больше не получишь. мальчик, после процитированого можешь даже не продолжать высказывать "авторитетное" мнение. а засрать 5гбит хламом мозгов даже твоих хватит, даже на линуксе, даже на 1 коробке. это точно.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	154. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 13-Янв-16, 23:26
	в рамках флейма - в 40GigE вливали 8Gbyte/s с линукса
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	155. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
	Сообщение от Аноним (??) on 14-Янв-16, 01:04
	> в рамках флейма - в 40GigE вливали 8Gbyte/s с линукса Это понятно. С линукс он такой, он в 40-гигабитную сетевуху может не только 8гигабайт x 8 бит = 64 гигабита влить. Он может и гораздо больше. Применение DPDK вообще дает все over9000 гигабит в секунду. А тонкий тюнинг ведра поняшками и того больше
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	156. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от тигар (ok) on 14-Янв-16, 08:35
	>> в рамках флейма - в 40GigE вливали 8Gbyte/s с линукса > Это понятно. С линукс он такой, он в 40-гигабитную сетевуху может не > только 8гигабайт x 8 бит = 64 гигабита влить. Он может > и гораздо больше. Применение DPDK вообще дает все over9000 гигабит в > секунду. А тонкий тюнинг ведра поняшками и того больше зачем ты это сделал? ЗЫЖ интересно, а иксперт принесший DPDK в обсуждение сабжа пропал из комментов т.к. уже понял в чем он был не прав или где?:-) ЗЗЫЖ интересно, как только родится новость (если родится) о полной поддержке всех фичей dpdk под фрей, будет ли обсуждение в комментах вокруг "зажать код, подстилки, BSDL!!111кококо" или тихонечко промолчат?
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	157. "В состав FreeBSD принята высокопроизводительная реализация s..."	+1 +/–
	Сообщение от Аноним (??) on 14-Янв-16, 14:04
	> как только родится новость (если родится) о полной поддержке всех фичей dpdk под фрей, Мечтай, под бздами всё так > зажать код, пoдстилки, BSDL!!111 Сам признался.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	158. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 14-Янв-16, 17:14
	> Мечтай, под бздами всё так http://www.intel.com/content/dam/www/public/us/en/documents/... Но вы продолжайте лучше оперативно минусовать все упоминания о бздах – на большее вы, очевидно, все равно не способны.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

114. "В состав FreeBSD принята высокопроизводительная реализация s..."	–1 +/–
Сообщение от rvs2016 (ok) on 11-Янв-16, 16:53
> копирование производится в фоне с мгновенным возвращением управления Если управление возвращается мгновенно, но мгновенно файлы не копируются, а продолжают копироваться и после этого мгновения, то как я узнаю результат копирования после возвращения управления мне? :-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	116. "В состав FreeBSD принята высокопроизводительная реализация s..."	+/–
	Сообщение от Аноним (??) on 11-Янв-16, 17:36
	> как я узнаю результат копирования после возвращения управления мне? Как это сделано в subj-е я не знаю, но в тексте явно упоминался асинхронный режим. Это значит что по завершению должен дергаться коллбек или генерится к-нота или еще как-то формироваться извещение. В этом извещении и должен быть код ошибки.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема