Группа исследователей, среди которых небезызвестный разработчик FreeBSD Роберт Ватсон, провела (http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013...) эксперимент (отчёт в PDF (http://conferences.sigcomm.org/hotnets/2013/papers/hotnets-f...)) по оценке эффективности реализации высокопроизводительного TCP/IP стека, работающей в пространстве пользователя и напрямую взаимодействующей с сетевой картой для отправки пакетов минуя дополнительные прослойки и исключая операции копирования данных (zerocopy).Для тестов был создан http-сервер Sandstorm, написанный с задействованием Netmap Framework (http://info.iet.unipi.it/~luigi/netmap/) для маппинга буфера сетевой карты в пространство пользователя и прямого взаимодействия с сетевым адаптером, минуя сетевую подсистему ядра ОС. В Sandstorm используется собственная реализация слоя для работы с Ethernet и легковесный TCP/IP-стек. TCP/IP-стек был оптимизирован специально для отдачи файлов небольшого размера, что дало преимущество перед штатными TCP-стеками Linux и FreeBSD, которые спроектированы для обеспечения высокой пропускной способности при длительных передачах (например, при передаче файлов по 8 Кб была достигнута 85% загрузка CPU, но удалось задействовать только половину возможной пропускной способности сетевого адаптера).
В итоге эксперимента, удалось добиться производительности сервера Sandstorm, заметно опережающей системы, использующие штатный системный TCP/IP стек. Например, Sandstorm продемонстрировал пропускную способность, заметно опережающую nginx, при этом меньше нагружал CPU.
Результаты тестирования на сервере с четырёхядерном CPU Intel Xeon E5-2643, 128GB ОЗУ и двухпортовой картой Intel 82599EB 10Gb:
<center><img src="http://www.opennet.me/opennews/pics_base/0_1386867474.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center><center><img src="http://www.opennet.me/opennews/pics_base/0_1386867488.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
На менее мощном сервере (8GB ОЗУ, двухядерный CPU Intel Xeon X5355 и идентичная двухпортовая карта Intel 82599EB 10Gb) разница более заметна:<center><img src="http://www.opennet.me/opennews/pics_base/0_1386866990.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
<center><img src="http://www.opennet.me/opennews/pics_base/0_1386867003.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
Код Sandstorm планируется открыть под свободной лицензией в течение нескольких месяцев, после его доработки до пригодного для широкого использования вида.
URL: http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013...
Новость: http://www.opennet.me/opennews/art.shtml?num=38653
Молодцы, результат предсказуем - ОС убрать будет еще быстрее. Даешь специализированный HTTP процессор!
> Молодцы, результат предсказуем - ОС убрать будет еще быстрее. Даешь специализированный
> HTTP процессор!Помнишь, чувак, игры под MS DOS? На DOS4GW написанные? Как они летали, м?
Ничто не ново, говорите, под луной?
>> Молодцы, результат предсказуем - ОС убрать будет еще быстрее. Даешь специализированный
>> HTTP процессор!
> Помнишь, чувак, игры под MS DOS? На DOS4GW написанные? Как они летали, м?Назначение его помнишь?
Вне всякого сомнения, павлиня. Чем XMS отличается от EMM и накуя лепили собственный экстендер мне известно не понаслышке.
Замечательно, как методы удлинения члена в досе связаны с расширением кАнала в BSD?
Следи за руками. Речь шла всего лишь о том, что для прогона тяжеловесных игрулин с текстурами и графикой наличия венды вовсе не требовалось.
> венды вовсе не требовалось.640k хватит всем!
>> венды вовсе не требовалось.
> 640k хватит всем!Передергиваешь. По существу сказать нечего?
По какому существу? Dos4gw пистатая шняга - для него написаны самые глючные софтины!
Сейчас сдох и 20 лет никому нахер не упёрся, никрофилим дальше?
> По какому существу? Dos4gw пистатая шняга - для него написаны самые глючные
> софтины!Следи за руками. Речь шла всего лишь о том, что для прогона тяжеловесных игрулин с текстурами и графикой наличия s/венды/любой_оси_общего_назначения вовсе не требовалось.
Так понятно?
> вовсе не требовалось.Уак бы DOS все-таки требовался...
ДОС была всего лишь шнягой, которая в позволяла софту работать с файловой системой. Почти все остальное, кроме дискового ввода-вывода обеспечивалось прерываниями BIOS-а. Это уж никак не тянет на полноценную ОС общего назначения.
А помните, в каком видеорежиме работали все те игры под dos4gw? 320x200x8. А помните, сколько моделей звуковых карт тогда поддерживалось теми играми? 5-7.Сейчас для запуска игр потребуется что-то посущественнее. Нужно что-то, что позволит поддерживать полдесятка различных видеокарт, несколько десятков звуковых карт, а также разного рода геймпады, рули, педали, беспроводные клавиатуры, веб-камеры. Времена dos4gw прошли.
есть нюанс - требовался защищенный режим, который и предоставлял dos4gw. Объяснять, что такое защищенный режим, многопользовательская и/или многопроцессная среда, надо?
> есть нюанс - требовался защищенный режим, который и предоставлял dos4gw. Объяснять, что
> такое защищенный режим, многопользовательская и/или многопроцессная среда, надо?Надо объяснять, что защищенный режим, многопользовательская и многопроцессная среда - это три большие разницы?
> есть нюанс - требовался защищенный режим, который и предоставлял dos4gw. Объяснять, что
> такое защищенный режим, многопользовательская и/или многопроцессная среда, надо?Надо объяснять, что это всего лишь код? )
Пит буль!
Если бы там не было DOS4GW, а была возможность нормальной работы с расширенной памятью - летало бы ещё быстрее.
> Если бы там не было DOS4GW, а была возможность нормальной работы с
> расширенной памятью - летало бы ещё быстрее.Откуда ей было взяться в архитектуре x86?
Ыксперт ёпта! А с заменой MS-DOS'a на тот же линь - архитектура x86 внезапно менялась? Мысль свежа и молодёжна - тебя ждёт карьера в Школково :)
Начиная с i386 процессор умел работать в т.н. unreal mode, который представляет собой подвид реального режима, но с 32битной адресацией. Собственно это фактически SMM режим.Да, драйвер XMS работал именно таким образом. Только входил в него не совсем типично, классическим способом является вход в PM и выход без перезагрузки дексрипторов кроме CS, XMS стрелял через loadall386 (что надо сказать намного удобнее).
не очень, особенно в области больших значений
Мысль не так уж и безрассудна. Есть же TCP Offloading, почему бы не быть и HTTP Offloading'у? А если еще SATA-контроллеры заменить на специализированные SQL-контроллеры, можно было бы добиться существенного увеличения производительности веб-серверов.
> Мысль не так уж и безрассудна. Есть же TCP Offloading, почему бы
> не быть и HTTP Offloading'у? А если еще SATA-контроллеры заменить на
> специализированные SQL-контроллеры, можно было бы добиться существенного увеличения
> производительности веб-серверов.Вот так 40 лет назад и изобрели промышленные компьютеры с микроядрами и DSP,
управляющие контроллерами и не участвующие в вычислениях.А ещо есть MPLS и прочие магистральные плюшки, так там ваще парсеры не нужны, тока маркеры!!!
Даёшь каждому юзеру в дом RAW трафик! А то понакупили гигафлопных кипятильников,
- вот вам делать нефига, сидите и парсите. :)
Какй ещё raw трафик?
блобы в шланге
Хм, снова к СКД-дискам и "машинам баз данных"?
Звучит заманчиво. Думаете взлетит на этот раз?
Когда-нибудь взлетит, т.к. данных всё больше, и всё больше идей и хотелок упирается в железо, сейчас пока ещё железо немного "улучшается" в рамках существующих архитектур, но со временем возможностей экстенсивного развития всё меньше.
Расширение путем добавления новых машин никто не отменял. А стоимость затачивания софта под железо обычно выше, чем стоимость железа.ПС. О проблемах масштабирования, CAP теореме и законе Амдалла я в курсе
>почему бы не быть и HTTP Offloading'у1. невозможность аудита
2. невозможностью пофиксить найденные проблемымне это напоминает историю с "драйверами" для GPU на raspberry pi - вроде бы и драйвера, а весь код отрисовки находится в ПЗУ, закрыт и проприетарен
драйверЫ же! Хотя, судя по контексту, скорее вообще "драйвер".
> Молодцы, результат предсказуем - ОС убрать будет еще быстрее.Что характерно, у пингвиноидов HTTP сервак в ядре был уже сто лет назад, только оказалось нишевой штукой, мало кому нужной.
Что еще характернее, в ответ на громкие заявы местных бздeльников по поводу того как нжинкс лучше работает под фряхой, сами фряшники выкатили графики, показывающие что пингвин работает гораздо лучше. Epic!
> Что характерно, у пингвиноидов HTTP сервак в ядре был уже сто лет
> назад, только оказалось нишевой штукой, мало кому нужной.И только на 18й день Зоркий Глаз заметил что в статье ___не___ про сервер в ядре.
> И только на 18й день Зоркий Глаз заметил что в статье ___не___
> про сервер в ядре.Но тоже примерно из той же области - некий самопал, который все сам. Вопрос на засыпку: сколько лет он будет доходить до кондиции если не nginx то хотя-бы лайти? Ну или кому и нафига оно такое будет надо? Пэтому и отправится вслед за пингвиньими серваками в ядре.
> Ну или кому и нафига оно такое будет надо?Засунуть в виртуалку, в облака...
> Засунуть в виртуалку, в облака...Очень удивлюсь, если эта штука заработает в виртуалке без запихивания кучи кода в драйвер virtio.
Еще больше удивлюсь, если удастся заставить несколько таких виртуалок использовать одну физическую сетевую карту. Это ж придется глобальный планировщик добавлять, который все просадит до обычного уровня.> виртуалку, в облака...
Или ты просто тонко намекаешь, что это все ненужная маркетологическая фигня?
Низкоуровневый код нужно совместить с nginx и будет вам и быстро, и удобно, и надёжно, т.е. фактически послать линукс на х., оставив только связку сетевая карта+nginx
> Низкоуровневый код нужно совместить с nginx и будет вам и быстро, и
> удобно, и надёжно, т.е. фактически послать линукс на х., оставив только
> связку сетевая карта+nginxПомечтай....
> Молодцы, результат предсказуем - ОС убрать будет еще быстрее. Даешь специализированный
> HTTP процессор!Судя по графикам они не то что Фрю они линукс настроить не смогли ...
> Судя по графикам они не то что Фрю они линукс настроить не смогли ...Ну да, ща нам nagual уроки системного программирования и тюнинга дадет. Он же эксперт... в дефрагментации NTFS-ов, как обычно :).
> HTTP процессор!В ASIC захардкодить :)
> Молодцы, результат предсказуем - ОС убрать будет еще быстрее. Даешь специализированный
> HTTP процессор!Было бы еще что в этом HTTP обсчитывать...
HTTP-процессор
> HTTP-процессорхочешь?
Хм, заодно разница между стеками линукса и фри видна. Фанатам фри на заметочку ;-)А вообще - если б он ещё отдельно протестировал как-нибудь прямое взаимоедйствие с картой и этот свой кастомный стек - было бы толку больше.
> Фанатам фри на заметочку ;-)Да-да, начинай, я записываю.
Лучше закусывай
Лучше помалкивай, если нечего сказать по существу, за умного сойдешь.
> Да-да, начинай, я записываю.Ну так запиши: вранье фанатов фряхи про то что нжинкс лучше работает в фре - полный булшит. Доказано бенчмарками от ... фряшников :).
Я вот лично рад что фря отстаёт. Так больше шансов что пингвиньё, готовое сотыми долями процента меряться, полопается от полного превосходства.
сотые доли процента полезно помнить, когда доказывается превосходство обратной стороны (читать bsd) над линуксом, а не только наоборот.
> готовое сотыми долями процента меряться,В вон тех 20% разницы по CPU load - сотых долей процентов довольно много, не находите? :)
> Я вот лично рад что фря отстаёт. Так больше шансов что пингвиньё,
> готовое сотыми долями процента меряться, полопается от полного превосходства.Ну фряшники же не лопались, когда рассказывали о своем превосходстве "в разы" (правда, без бенчмарков и прочих пруфов).
> Ну фряшники же не лопались, когда рассказывали о своем превосходстве "в разы"
> (правда, без бенчмарков и прочих пруфов).Как не зайду на опеннет обязательно кто-то обсирает фряшников, причем без разбору всех и сразу. У вам комплекс неполноценности или что?
Ну так посмотри на предпоследний график: на современном железе с 6 сетевухами FreeBSD+nginx выдаёт примерно на треть больше, чем Linux+nginx. Или красноглазие глаза застит?
> FreeBSD+nginx выдаёт примерно на треть больше, чем Linux+nginx. Или кра сноглазие глаза застит?Ну, как бы, "исследователи", которые "Interestingly, we have experienced a collapse on Linux with six NICs.", и "среди которых небезызвестный разработчик FreeBSD", это последняя инстанция в установлении "на треть больше", да. Через пару недель, если _мне повезёт, кто-нибуть из линукс-сетевиков и/или ядерщиков разберёт по косточкам, что сии исследователи сделати не так, как это надо было делать и сколько десятков процетнов или, моет быть, раз там "на самом деле" должно было бы получиться. Если не так повезёт, просто отбрехаются -- линуксоидам с Таким Железом(ТМ) работать надо, а не пиаром заниматься.
> Хм, заодно разница между стеками линукса и фри видна. Фанатам фри на
> заметочку ;-)Ну видно, что сетевой стек фри обеспечивает более ровное распределение канала по клиентам. За это приходится платить нагрузкой на процессор.
>> Хм, заодно разница между стеками линукса и фри видна. Фанатам фри на
>> заметочку ;-)
> Ну видно, что сетевой стек фри обеспечивает более ровное распределение канала по
> клиентам. За это приходится платить нагрузкой на процессор.Всем давно уже известно, клиент - говно, количество - главное.
БЗДя не вписывается в бизнес-модели.
> БЗДя не вписывается в бизнес-модели.Да она вообще вписывается только в придорожный кювет. Что с ней делать то? На серверах это нечто не умеет виртуализацию и контейнеры с полисовкой реусруов, пакетный менеджер - где-то в теории, чисто для галочки, на выбор две ФС: древняя и тормозная и энтерпрайзная и тормозная. С таким @#$нутым управлением проектом бизнес на этом делать себе дороже: в два счет пойдешь заявление о банкротстве подавать.
Справедливости ради, стоит заметить следующее:По вашим тезисам:
1. ZFS не такая уж и тормозная ФС. Насколько я помню, тесты говорят скорее об обратном.
2. Пакетный менеджер? Там есть «порты» и FreeBSD-шников они вполне устраивают (как и Gentoo-шников их portage).
3. Контейнеры? Вообще-то во FreeBSD jail-ы появились _значительно_ раньше, чем в linux LXC. К тому же LXC до сих пор не предоставляет достаточно полной изоляции и вообще ещё зелёный. Хотя штука вкусная, конечно :)
4. Виртуализация? Что-нибудь слышали про "bhyve"? И я хоть и не знаю насколько там сейчас работает VirtualBox, но судя по [1] и [2], очень даже работает.[1] https://wiki.freebsd.org/VirtualBox
[2] http://www.ru.freebsd.org/doc/handbook/virtualization-host.htmlКонтртезисы:
1. Во Фре не устраивали такой бардак с user-space утилитами для управления ядром. Например, хочешь управлять сетевыми интерейсами - есть ifconfig, хочешь маршрутизацией - есть route. А в linux чтобы управлять сетевыми интерфейсами и маршрутизацией по старой традиции требуется: ifconfig, iwconfig, iwlist, iw{куча_другой_хрени}, route, ip, ifenslave, vconfig, brctl, hostapd и что-нибудь ещё (однако честности ради, сейчас всё упаковывают в "ip"). Притом даже несмотря на переход на "ip", если во многих дистрибутивах, например, удалить "vconfig", то init-скрипты уже будут неспособны настроить dot1q-интерфейсы.
2. Во Фре элементарные вещи делаются элементарно. Чисто для примера там есть до жути простой шейпер «DUMMYNET», который требует 30-60 секунд настройки для простого домашнего маршрутизатора и замечательно работает.
3. Фря с точки зрения «бизнеса» важна тем, что эта неплохая ОС с более permissive лицензией (чем у Linux), что необходимо для таких компаний, как например Juniper.
И не надо думать, что я Фряшник. Я FreeBSD уже давно не пользуюсь...(
> Справедливости ради, стоит заметить следующее:А я добавлю, что держусь на FreeBSD именно как раз за счет виртуализации. Jail + vnet + RCTL - все, что нужно. И все "из коробки", никаких форс мажоров при обновлении. Вот как раз в бизнесе самое то.
>> Справедливости ради, стоит заметить следующее:
> А я добавлю, что держусь на FreeBSD именно как раз за счет
> виртуализации. Jail + vnet + RCTL - все, что нужно. И
> все "из коробки", никаких форс мажоров при обновлении. Вот как раз
> в бизнесе самое то.Ну, претензий к FreeBSD у меня тоже хватает. Но я не сторонник считать, что FreeBSD лучше/хуже Linux. Я, конечно, понимаю, что это очень банальная мысль, но по мне дак они просто решают разные задачи. :)
> Ну, претензий к FreeBSD у меня тоже хватает. Но я не сторонник
> считать, что FreeBSD лучше/хуже Linux. Я, конечно, понимаю, что это очень
> банальная мысль, но по мне дак они просто решают разные задачи.
> :)Просветите опеннет, что же всё таки решает freebsd, и для чего она
предпочтительней линуксов?
>> Ну, претензий к FreeBSD у меня тоже хватает. Но я не сторонник
>> считать, что FreeBSD лучше/хуже Linux. Я, конечно, понимаю, что это очень
>> банальная мысль, но по мне дак они просто решают разные задачи.
>> :)
> Просветите опеннет, что же всё таки решает freebsd, и для чего она
> предпочтительней линуксов?Для каждой задачи нужно использовать то что лучше подходит, вот например в win2008R2 отлично идет BF3 :))
"в общем" - гибче, меньше проблем, легче управлять, реже что-то ломают., но при этом нет нужды сидеть на древнючем софте (как, например, в редхате и дебиане).по вопросу - во всём, что она умеет. если нужно что-то сверху - тогда в веллкамм тууу линукс.
>>Просветите опеннет, что же всё таки решает freebsd, и для чего она
>>предпочтительней линуксов?
> "в общем" - гибче, меньше проблем, легче управлять, реже что-то ломают., ноконкретику плиз -- этот маркетинговый сленг не нужно -- конкретику подавай, что такое "в общем", кто и куда и зачем нагибает?
управлять легче что? то что знакомо? кто и что ломают в Linux (RHEL/Debian)> при этом нет нужды сидеть на древнючем софте (как, например, в
> редхате и дебиане).кто? КТО? я вас спрашиваю заставляет вас сидеть на "древнючем" , какое количество совта из системы/дистрибутива нужна в виде bleeding edge? в процентах?
> по вопросу - во всём, что она умеет. если нужно что-то сверху
что она умеет лучше?
> - тогда в веллкамм тууу линукс.
> конкретику плизага, иди и читай. ты уже тут стопиццотый, с незамутнённым "а шо такое?"
> управлять легче что?
управлять легче - всё. не переименовывают логи, не втыкают systemd, не ломают wifi, вебкамы. не всандаливают стопиццот систем инициализации и у-каждого-своё-понятие-о-конфигах. hald впили, выпилили. udev впилили, ща будут выпиливать и systemd впиливать. cciss выпилили, hpsa впилили, часть контроллеров дропнули. раньше ещё и планировщик был уродский. la в 20-ку - по ssh уже не зайти. легче собирается софт с кастомными флагами.
фря не замахивает мелкими непрерывными проблемами на новых инсталлах.
> кто и что ломают в Linux (RHEL/Debian)OpenSSL + Debian + /dev/random, не?
> кто? КТО? я вас спрашиваю заставляет вас сидеть на "древнючем" ,
выбор "или всё ломают, или жри окаменевшее" нравится не всем. и да, в окаменевшем тоже ломают, беда.
> какое количество совта из системы/дистрибутива нужна в виде bleeding edge? в процентах?
дебиан: астер 1.8.*
bleeding edge это что? 10.*? 11.*? 12.*? 14.*?
какое количество софта нужно в виде древнего говна? в процентах?
> что она умеет лучше?
достаточно "так же". на удобстве управления уже профит. другими словами - не десктоп? не виртуализация? линукс не нужен, да ;-)
>> конкретику плиз
> ага, иди и читай. ты уже тут стопиццотый, с незамутнённым "а шо
> такое?"
>> управлять легче что?
> управлять легче - всё.читаю как "ну не шмогла я -- не шмогла!"
> не переименовывают логи, не втыкают systemd, не ломают
> wifi, вебкамы. не всандаливают стопиццот систем инициализации и у-каждого-своё-понятие-о-конфигах.какие логи? нет -- я правда не понимаю -- даже в случае (допустим) сменили /var/log/syslog на любимое бсд messages в чем поблема?
где в RHEL и/или Debian systemd? кто-то тут фантазирует.
а фо фряхе уже есть wifi? ой -- ну только не нада мне расказывать -- те два с половиной адаптера работающих в непонятных режимах с дровами требующими перегрузки и отваливанием связи.
про 100500 систем инита 1 -- кто вас заставляет (предлагают да -- но кто заставляет) --
отчего возможность выбора стала не преимуществом а недостатком? (резко вспоминается девиз "Если нету - значит не нужно")> hald впили, выпилили. udev впилили, ща будут выпиливать и systemd впиливать.
кто будет? знания о Linux из брошурки?
> cciss выпилили, hpsa впилили, часть контроллеров дропнули. раньше ещё и планировщик
> был уродский. la в 20-ку - по ssh уже не
> зайти. легче собирается софт с кастомными флагами.я правильно понял что локальные пертрубации с одним scsi драйвером это хоже чем отсутствие драйверов к 80%остального оборудования.
враньё с la>20 и ssh считаю написано исключительно для тролинга -- потому как действительности не соответствует.
> фря не замахивает мелкими непрерывными проблемами на новых инсталлах.опять маркетинг?
>> кто и что ломают в Linux (RHEL/Debian)
> OpenSSL + Debian + /dev/random, не?нет -- я сразу знал что этот косях будут вспоминать Debian'у очень долго -- но как оказалось я был оптимистом -- этого не забудут никогда. Но мы же знаем что все программы имеют ошибки и только fbsd идеальна -- подобные доводы идут мимо кассы.
что было с /dev/random?
>> кто? КТО? я вас спрашиваю заставляет вас сидеть на "древнючем" ,
> выбор "или всё ломают, или жри окаменевшее" нравится не всем. и да,
> в окаменевшем тоже ломают, беда.
>> какое количество совта из системы/дистрибутива нужна в виде bleeding edge? в процентах?
> дебиан: астер 1.8.*
> bleeding edge это что?http://en.wikipedia.org/wiki/Bleeding_edge_technology
>10.*? 11.*? 12.*? 14.*?т.е из >20000 пакетов понадобилось 5 новых -- поздравляю you do it wrong
> какое количество софта нужно в виде древнего говна? в процентах?
>> что она умеет лучше?
> достаточно "так же". на удобстве управления уже профит. другими словами - не
> десктоп? не виртуализация? линукс не нужен, да ;-)
> читаю как "ну не шмогла я -- не шмогла!"следовательно с пониманием прочитанного у тебя глубокие проблемы. ну или очень хочется выдать желаемое за действительное.
> (допустим) сменили /var/log/syslog на любимое бсд messages в чем поблема?
а зачем?
> где в RHEL и/или Debian systemd? кто-то тут фантазирует.
вот-вот, единственный способ отстраниться от падающих говн - держаться за древние говна. такой выбор нравится не всем.
> а фо фряхе уже есть wifi?
суть вопроса: в линуксе периодически ломали поддержку некоторых адаптеров. где здесь речь о фряхе? меня лично устраивает в гораздо большей степени ситуация "если есть, то есть, если нет, то нет", и не устраивает "сегодня есть, завтра сломали, послезавтра починили одно, сломали другое" и в качестве альтернативы "сиди на древнем говне, точно ничего не сломают". Ну вот не устраивает, представь.
> про 100500 систем инита 1 -- кто вас заставляет (предлагают да -- но кто заставляет)
никто не заставляет, верно. но поддерживать зоопарк слабо совместимых с собой велосипедов - удовольствие ниже среднего.
> отчего возможность выбора стала не преимуществом а недостатком?
ну например потому, что выбрал одно, а в комплекте идёт то, что выбирать не хочется совсем.
>> hald впили, выпилили. udev впилили, ща будут выпиливать и systemd впиливать.
> кто будет? знания о Linux из брошурки?мейнстрим будет там весь, помяни моё слово.
> я правильно понял что локальные пертрубации с одним scsi драйвером это хоже
> чем отсутствие драйверов к 80%остального оборудования.80% это троллингомаркетинг
> враньё с la>20 и ssh считаю написано исключительно для тролинга -- потому
> как действительности не соответствует.за давностию лет могу ошибаться в цифире. но факт, что до смены шедулера ssh на серваки с высоким LA в лялихе и фряхе отличались радикально в пользу фряхи.
>> фря не замахивает мелкими непрерывными проблемами на новых инсталлах.
> опять маркетинг?опыт, дружище, опыт.
>>> кто и что ломают в Linux (RHEL/Debian)
>> OpenSSL + Debian + /dev/random, не?
> нет -- я сразу знал что этот косях будут вспоминать Debian'увсякий раз, когда фанаты начинают врать про особую стабильность и какое-то немыслимое тестирование.
>> дебиан: астер 1.8.*
>> bleeding edge это что?
> http://en.wikipedia.org/wiki/Bleeding_edge_technologyне будь идиотом. я спросил тебя - какая из этих версий 10.* 11.* 12.* 14.* bleeding edge.
> т.е из >20000 пакетов понадобилось 5 новых -- поздравляю you do it wrongвообще-то один. вообще-то это пример. и вопрос принципиальный, и звучит он так:
отчего возможность выбора стала не преимуществом а недостатком? (резко вспоминается девиз "Если нету - значит не нужно")
я бы конечно спросил "ничьи слова не напоминает?", но я же понимаю, с кем имею дело - с фанатиком. а это значит те преимущества, которые даёт FreeBSD "не нужны", у линукса недостатков нет, при тычке в недостаток сразу "а у вас...".
дружище, я крайне не люблю публику, у которой фанатизм отключает мозг.
>> какое количество софта нужно в виде древнего говна? в процентах?не вижу ответа.
> десктоп? не
почему "не"? из-под линукса и пишу. уж лет пять десктоп под линуксом.
> виртуализация?
очень хорошая виртуализация. и если нужна именно она - то да, выбор очевиден. если она не нужна или достаточно того что есть во фре, то выбор не так очевиден.
> линукс не нужен, да ;-)
я так сказал? правда? где?
>[оверквотинг удален]
>>> какое количество софта нужно в виде древнего говна? в процентах?
> не вижу ответа.
>> десктоп? не
> почему "не"? из-под линукса и пишу. уж лет пять десктоп под линуксом.
>> виртуализация?
> очень хорошая виртуализация. и если нужна именно она - то да, выбор
> очевиден. если она не нужна или достаточно того что есть во
> фре, то выбор не так очевиден.
>> линукс не нужен, да ;-)
> я так сказал? правда? где?во первых -- ты смешон -- и смешон в первую очередь что пытаешся разговаривать сам с собой. половину вопросов на вопросы ты задал себе сам.
во вторых -- человек считающий "древним говном" то, на чём основная масса пользователей (администраторов)строит рабочую инфраструктуру не может восприниматься всерьёз.
в третьих -- твою (раз ты решил беззастенчиво перейти "на ты")попаболь нужно обязатно чем-то смазать, а то случиться нарыв и неизбежное.
> во первых -- ты смешон -- и смешон в первую очередь что пытаешся разговаривать сам с собой.извини, это получается автоматически. когда собеседник глух и/или туп, как пробка, получается, что говоришь сам с собой.
> во вторых -- человек считающий "древним говном" то, на чём основная масса
для глухих как пробка, повторю вопрос:
какая из версий астериска 10/11/12/14 bleeding edge?
для тупых поясняю:
это вопрос - тебе.основная масса это, несомненно, аргумент. тут, конечно, твоя правда. как же вразрез с основной массой. ты, главное, putty, не про*би с рабочего стола. небось десктоп-то как у основной массы?
> не может восприниматься всерьёз.
туповатый фанатик с опеннета не может меня воспринимать всерьёз. как бы это пережить-то, а?
> в третьих -- твою (раз ты решил беззастенчиво перейти "на ты") попаболь нужно обязатно чем-то смазать, а то случиться нарыв и неизбежное.
это лично твой опыт, или основной массы? ну всё равно спасибо конечно, за заботу. хотя я себя прекрасно чувствую.
> "в общем" - гибче, меньше проблем, легче управлять, реже что-то ломают., но
> при этом нет нужды сидеть на древнючем софте (как, например, в
> редхате и дебиане).
> по вопросу - во всём, что она умеет. если нужно что-то сверху
> - тогда в веллкамм тууу линукс.Во! Ключевая мысль "гибче, меньше проблем, легче управлять, реже что-то ломают".
Я никак не хочу спорить про то, что лучше. Лично я использую линукс только в железных роутерах с OpenWRT на борту. Но там, где клиенты выдвигают особые требования к безопасности\стабильности - никакого линуха!
о да, ifconfig мы еще 50 лет будем использовать;
мыши кололиcь, но продолжали жрать кактус
> о да, ifconfig мы еще 50 лет будем использовать;а что, уже немодно?
> мыши кололиcь, но продолжали жрать кактус
лично меня ifconfig не напрягает, это ж вы плакали, кололись и страдали. хотя несомненно на форумах кричали другое и громко.
> лично меня ifconfig не напрягает, это ж вы плакали, кололись и страдали.
> хотя несомненно на форумах кричали другое и громко.за всю сознательную жизнь на форуме задавал вопрос раз 6, и ни разу внятного ответа не получал, так что мимо.
пилять, ифконфиг это атавизм оставшийся со времен когда половина дров не умела 2-й айпишнег вешать, создание саб интерфейса с другим адресом - это бред сивой кобылы, разбейте пару 24 сетей на сети по 2-8 компов с общим шлюзом на одной карте и повесте туда пару вланов, да охереете разбирать где там влан, а где что.
Да пользуйтесь хоть виндой 95, но не надо гнать, что она не хуже современных осей, за последние 10 лет изменений в стэке ip линукса произошла масса, и пихать и прикручивать новые возможности к старым системам управления, это как в ракеты руль с тремя педалями мастрячить, не надо вам сидите с ифконфигом никто его не трогает, а современные реалии требуют современных инструментов.
>гибче,Гибче - это когда нужно пересобирать ради того, чтобы что-то _отключить_, как во фре? Вместо того, чтобы доставить _дополнительный_ пакет, когда он потребуется, как других системах?
>меньше проблем
Это когда нужно закрыть уязвимость в пакете и ради этого пересобирать из портов полсистемы?
Это когда NAT не умеет транслировать GRE и PPTP? Это когда pf не умеет толком распараллелиться на несколько процессорных ядер? Это когда Linux держит раза в 3 больше NAT-трансляций, чем фря?
>легче управлять
Файликом /etc/resolv.conf вручную управлять безусловно легче. Особенно если нет динамически настраиваемых интерфейсов. В противном случае начинается костылестроение с написанием скриптов, обновляющих resolv.conf при поднятии и опускании интерфейса.
В нормальных дистрибутивах можно выставить приоритеты интерфейсам, а при их поднятии и опускании DNS-серверы, динамически полученные через DHCP или IPCP, сами пропишутся на нужное место в этом файлике. А если ещё понадобится при всём при этом настроить кэширующий DNS-сервер, то тут бсдуны уходят в штопор, не в силах решить эту проблему. Они просто говорят, что это не нужно.
Легче сношаться с portmaster'ом, чем ввести apt-get upgrade?
>реже что-то ломают
Это когда перед обновлением портов нужно прочитать специальный текстовый файлик и делать какие-то телодвижения, для того чтобы просто заменить pkgconf на pkg-cconfig, пересобрав при этом все пакеты, зависящие от него. В нормальных системах с пакетным менеджером не из прошлого века в свойствах пакета мэйнтейнеры сами прописывают, какой устаревший пакет он заменяет. Накат обновлений зачастую проходит вообще без вмешательства человека и вообще без компиляции.
Реже ломают, потому что ломать-то особо нечего. Ни тебе полноценной контейнерной виртуализации с разграничением ресурсов, ни тебе Xen dom0, ни паравиртуализированных драйверов для amd64.
>>гибче,
> Гибче - это когда нужно пересобирать ради того, чтобы что-то _отключить_,в модульных системах, для того, чтобы что-то отключить, достаточно не грузить соответствующий модуль. Так сделано в apache/php/asterisk/etc.
в немодульных системах, например использовать pthreads или openmp естественно надо пересобрать, коли речь о source-based, где это штатный способ установки. почему это проблема - неясно. и да, в данном случае "поставить дополнительный пакет - не получится, верно?
>>меньше проблем
> Это когда нужно закрыть уязвимость в пакете и ради этого пересобирать из
> портов полсистемы?утрирование - одно из самых сильных орудий демагога.
> Это когда NAT не умеет транслировать GRE и PPTP?
Какой-то умеет, какой-то не умеет. Если это надо, надо взять тот, который умеет.
alias_pptp.ko, ipfw.> Это когда pf не умеет толком распараллелиться на несколько процессорных ядер?
дык pf не единственное наше всё. и да, таки умеет с патчами в 8-ке/9-ке и в 10-ке будет штатно.
> Это когда Linux держит раза в 3 больше NAT-трансляций, чем фря?
(пожимает плечами) это ты померял в ситуации когда "не умеет". А когда - умеет?
>>легче управлять
> Файликом /etc/resolv.conf вручную управлять безусловно легче.# psearch name=openresolv
Port: openresolv-1.1
Path: /usr/ports/dns/openresolv
Info: A resolvconf compatible framework for managing resolv.confТы не это искал?
> нужное место в этом файлике. А если ещё понадобится при всём при этом настроить кэширующий DNS-сервер, то тут бсдуны уходят в штопор, не в силах решить эту проблему. Они просто говорят, что это не нужно.какая проблема с кэширующим сервером?
> Легче сношаться с portmaster'ом, чем ввести apt-get upgrade?
Сношаться несомненно не легче. Но с другой стороны сношаться с apt-get тоже не легче, чем просто поставить portmaster-ом.
>>реже что-то ломают
> Это когда перед обновлением портов нужно прочитать специальный текстовый файлик и делать
> какие-то телодвижения, для того чтобы просто заменить pkgconf на pkg-cconfigкак часто меняется pkgconf на pkg-config? где вам обещали в линуксе (и в каком), что вам ничего читать не нужно и никаких телодвижений не понадобится?
>, пересобрав при этом все пакеты, зависящие от него.чем это фатально хуже по сравнению с "переустановить все пакеты, зависящие от него", при условии что сборка это штатный способ установки?
> В нормальных системах с пакетным менеджером не из прошлого века в свойствах пакета мэйнтейнеры сами прописывают, какой устаревший пакет он заменяет.
один раз я сталкивался с такой проблемой - для php пришлось вручную указать что новый пакет заменяет старый. а в основном-да, майнтейнеры сами прописывают
> Накат обновлений зачастую проходит вообще без вмешательства человека
неясно что имеется ввиду. накатывание обновлений автоматом? это сомнительное удовольствие, хотя если вручную на тестовом прошло, то можно и автоматом на остальных. и порты этому никак не мешают. как минимум я хочу выбрать время рестарта обновлённого сервиса.
> и вообще без компиляции.
у вас органическое неприятие компиляции? мне, например, оно не мешает. и да, есть возможность ставить бинарями.
> Реже ломают, потому что ломать-то особо нечего.
Утрирование, попытка №2.
> Ни тебе полноценной контейнерной виртуализации с разграничением ресурсов, ни тебе Xen dom0, ни паравиртуализированных драйверов для amd64.
Ежели нужна виртуализация, никто не мешает взять лялих, где с ней заметно лучше. Но нужна она не всегда и не всем и в разных объёмах.
> Но там, где клиенты выдвигают особые требования к безопасности\стабильности - никакого линуха!Рискну оспорить в плане безопасности. Безопасность это а) комплекс мер, сиречь архитектура б) процесс. Тут имеет значение наличие чёткой политики безопасности (для исполнения п. "а") и следование ей и отслеживание уязвимостей (для "б"). Это несколько ортогонально ОС и если ты или я выбираем в данном случае BSD - это говорит только о том, что для BSD *у тебя* более чёткая политика безопасности. Т.е., грубо говоря ты её лучше знаешь и больше доверяешь. Тот, кто лучше знает Linux, при наличии *чёткой политики безопасности*, выберет линукс и будет прав.
>> Но там, где клиенты выдвигают особые требования к безопасности\стабильности - никакого линуха!
> Рискну оспорить в плане безопасности. Безопасность это а) комплекс мер, сиречь архитектура
> б) процесс. Тут имеет значение наличие чёткой политики безопасности (для исполнения
> п. "а") и следование ей и отслеживание уязвимостей (для "б"). Это
> несколько ортогонально ОС и если ты или я выбираем в данном
> случае BSD - это говорит только о том, что для BSD
> *у тебя* более чёткая политика безопасности. Т.е., грубо говоря ты её
> лучше знаешь и больше доверяешь. Тот, кто лучше знает Linux, при
> наличии *чёткой политики безопасности*, выберет линукс и будет прав.В принципе ты прав. :-) Можно с обоюдным успехом настроить систему с "security in mind": хоть FreeBSD, хоть Linux. Я просто определил те задачи, которые лучше решает именно эта ОС и там ее использую.
>> Справедливости ради, стоит заметить следующее:
> А я добавлю, что держусь на FreeBSD именно как раз за счет
> виртуализации. Jail + vnet + RCTL - все, что нужно. И
> все "из коробки", никаких форс мажоров при обновлении. Вот как раз
> в бизнесе самое то.а у меня вопрос: каждый быэсдэшник путает виртуализацию с изоляцией?
> а у меня вопрос: каждый быэсдэшник путает виртуализацию с изоляцией?Нормальной продакшен-виртуализации там нет в принципе, поэтому _фряшникам_ данные термины можно не различать.
>>> Справедливости ради, стоит заметить следующее:
>> А я добавлю, что держусь на FreeBSD именно как раз за счет
>> виртуализации. Jail + vnet + RCTL - все, что нужно. И
>> все "из коробки", никаких форс мажоров при обновлении. Вот как раз
>> в бизнесе самое то.
> а у меня вопрос: каждый быэсдэшник путает виртуализацию с изоляцией?Мсье, вы путаете классический чрут с виртуализацией на уровне ОС.
Читаем хотя бы тут http://ru.wikipedia.org/wiki/%D0%92%D0%B...
Расскажи, как в jail-е человеческим образом лимитить память, cpu и disk io.
> Расскажи, как в jail-е человеческим образом лимитить память, cpu и disk io.ты не понял -- он же сразу сказал что ему больше не нужно. и я даже скажу почему не нужно - потому что уже много лет они пропагандуруют лозунг "Если нет - значит не нужно".
> Расскажи, как в jail-е человеческим образом лимитить память, cpu и disk io.В 9.2 - нормально. man rctl
i/o throttling не вижу. Но вообще прогресс. Было бы вот это и pkgng 4 года назад, глядишь, не ушел бы с фри.
> i/o throttling не вижу. Но вообще прогресс.о чём и речь.
> Было бы вот это и pkgng 4 года назад, глядишь, не ушел бы с фри.
не разделяю такой подход. это не религия, не семья и даже не место работы. "ушёл/вернулся" - не очень применимо. "Использую/не использую". Собственно ничто не мешает использовать то, что удобно. Когда фряху на десктопе стало неудобно использовать (на новом железе) - я стал использовать удобный мне линукс. Будет удобно использовать - буду использовать. Ну и так в общем-то со всем.
> А я добавлю, что держусь на FreeBSD именно как раз за счет
> виртуализации. Jail + vnet + RCTL - все, что нужно. И
> все "из коробки", никаких форс мажоров при обновлении. Вот как раз
> в бизнесе самое то.Человек, который всю жизнь питался кактусами, просто не верит, что бывает более вкусная, полезная и менее травмирующая пища =)
> 2. Во Фре элементарные вещи делаются элементарно. Чисто для примера там есть до жути простой шейпер «DUMMYNET»Для меня DUMMYNET и шейпинг посредством него был откровением. Разобрался и настроил за пол-часа. Когда-то в линуксе с помощью iproute2 tc решал похожую задачу и парился очень долго... В FreeBSD это ИМХО проще всё сделано и понятнее.
Однако задача была простая, всякие сложные конфигурации не пробовал.
По контртезису 1. В arch linux кроме ip уже ничего нет. Скоро так будет везде.
Добавлю еще контртезисов:1) в линуксе нельзя из listen 0.0.0.0:port изъять конкретный ip. Это делает переконфигурацию вида "вытащить один айпи для другого сервиса" без потери соединений невозможной. В bsd можно просто сделать более частный бинд-листен и это будет работать.
2) действительно, ряд простых вещей делается в линуксе сложнее. Например, получить BSD-шный netstat -lan (размер listening queue) в линуксе можно получить только косвенно, например, с помощью awk.
Хотя я сам давно на линуксе. :)
> 1) в линуксе нельзя из listen 0.0.0.0:port изъять конкретный ip.Это напоминает "сначала положим грабельки вот сюда, а потом с разбегу на них прыгнем".
Когда нужна избирательность по IP, слушать 0.0.0.0 будет только ССЗБ.
Год была не нужна, потом понадобилось. Дропать соединения - не хочется. Что делать?
> Год была не нужна, потом понадобилось. Дропать соединения - не хочется. Что
> делать?В общем-то изменение параметров слушаемого сокета - не единственное, что может потребоваться. Может быть тысяча причин перезапустить демон и коннекты не хочется терять никогда. Если используемый демон не поддерживает graceful restart, наверное, надо чинить его самого в первую очередь.
Ну или хотя бы graceful stop. У вас ведь сервис за балансировщиком сидит, если вам даже рвать соединение не хочется, правда?
Graceful restart есть, конечно. И балансер есть. Так в итоге и сделал. Но был неприятно удивлен несоответствием линуксовой реализации каноничным bsd sockets.
> Это напоминает "сначала положим грабельки вот сюда, а потом с разбегу на
> них прыгнем".
> Когда нужна избирательность по IP, слушать 0.0.0.0 будет только ССЗБ.это напоминает сакраментальное "если нет, то не надо"
> Ну видно, что сетевой стек фри обеспечивает более ровноеНифига, более ЧЕТКОЕ. Это более в духе фряшных "одминов".
>Ну видно, что сетевой стек фри обеспечивает более ровное распределениеУгу.
Ровнее только на нуле.Зыж
Да была уже новость на опеннете, что фря не просто линуху сливает, а даже вантузу проигрывает.
Х/з, там хоть можно было критиковать и пинать на объективность.
Но сабж то самим бсдишнегом и сделан.
Учитывая что процессор не загружен на 100% разница определяется прежде всего настройками TCP-стека. А поскольку тестировали netmap, а на BSD/Linux вряд ли они тратили время на настройку ядерного TCP-стека. И графики говорят только о том, что значения по умолчанию разные. Впрочем и для Linux и для BSD значения не позволяют в данном конкретном тесте добиться максимальной производительности на небольшой числе параллельних коннекций. Замечу что к реальным web-серверах этот участок графика имеет мало отношения. В жизни на нагруженых веб-серверах не десятки, а тысячи параллельных коннекций.
Эксплоит будет давать права рута, красота.
> Эксплоит будет давать права рута, красота.Не, чувак. Не рута. А ring 0 сразу. Рут там с@сет и нервно курит.
>> Эксплоит будет давать права рута, красота.
> Не, чувак. Не рута. А ring 0 сразу. Рут там с@сет и
> нервно курит.он и так даст права рута, если сможет ядро "подставить", тут же изыскание на тему -
"на сколько можно увеличить производительность системы, если исключить промежуточные звенья", вот тут показали на сколько это возможно, кто-то посмотрит, взвесит все за и против, и возможно реализует для своей конторы ( гугла или яндекса к примеру ).p.s. Да и если к примеру для сервиса типа Яндекс.Фоток, тупо на отдачу не защищаемого контента, то можно на многие вещи не обращать внимания.
>> Эксплоит будет давать права рута, красота.
> Не, чувак. Не рута. А ring 0 сразу. Рут там с@сет и нервно курит.Кроме некоторых редких случаев (типа селинукса или заблокированной загрузки модулей), разницы никакой.
Лучше бы он стек FreeBSD допилил до линуксового чем этой хренью занимался.
> Лучше бы он стек FreeBSD допилил до линуксового чем этой хренью занимался.Ничего вы не понимаете. На предъяву "ваш грузовик медленно ездит и маловато груза перевозит" бравый перец выкатил ракету. Ну и что что одноразовая и топливо жрет как не в себя? Зато круто и концептуально :).
Вот правильный скриншот http://www.fenrus.demon.nl/performance.html
Ядрённый сервер рвет апача, как тузик грелку!2500 запросов в секунду, а этот уже при 50 запросах сливает.
К слову, это куда более интересная идея, чем сервер со своим узкозаточенным tcpip стеком.
>Ядрённый сервер рвет апача, как тузик грелку!Вообще-то, на их графике nginx, который тоже как тузик грелку
>>Ядрённый сервер рвет апача, как тузик грелку!
> Вообще-то, на их графике nginx, который тоже как тузик грелкутут ядро 2.2.10, 20-летней давности, на 100 мегабитах :)
> Ядрённый сервер рвет апача, как тузик грелку!еле дышащих старичков было модно избивать лет 10 назад. Сейчас халява закончилась, нужно пробовать избить nginx или lighttpd
а ведь фряха сливает линю во всех тестах (ось + nginx)
> а ведь фряха сливает линю во всех тестах (ось + nginx)А мы не злопамятные, но память у нас хорошая, поэтому припомним местным спиди-гонщикам как они ВРАЛИ что нжинкс под фряхой работает якобы лучше чем в лине. А оказывается - это не только фанатский буллшит, но еще и сами фряшники это признают.
>> а ведь фряха сливает линю во всех тестах (ось + nginx)
> А мы не злопамятные, но память у нас хорошая, поэтому припомним местным
> спиди-гонщикам как они ВРАЛИ что нжинкс под фряхой работает якобы лучше
> чем в лине. А оказывается - это не только фанатский буллшит,
> но еще и сами фряшники это признают.Фанбои - это всегда плохо.
> Фанбои - это всегда плохо.Кому плохо, а кому - покушать и поднять настроение =)
Признайте уже, что Linux BUG #12309 до сих пор не пофикшен. ;)http://www.linux.org.ru/forum/general/9922995
http://www.linux.org.ru/forum/desktop/9591777
Сферический конь и не может быть пофикшен.
А у вас, а у вас.. а у вас нет фотожопа и автокада.
Вот.Зыж
Линух и с этим багом бсдю делал и теперь без него.
А я так вообще этот баг не встречал. Может с железом везло, а может я его выбирать умею.
А может на таком железе бсдя вообще не загрузится.
Автокад 2008 голдовая прожина вайна. Мимо
> Автокад 2008 голдовая прожина вайна. МимоСейчас бсдшники под линукслятором запустят в вайне виртуалку с автокадом, вам назло :).
>> Автокад 2008 голдовая прожина вайна. Мимо
> Сейчас бсдшники под линукслятором запустят в вайне виртуалку с автокадом, вам назло
> :).Зачем? Он у них и так запущен, вместе с путти и фотошопом.
> А я так вообще этот баг не встречал.а я например встречал.
> А может на таком железе бсдя вообще не загрузится.
скорее наоборот.
> а я например встречал.Ну я тоже могу охотничьих историй рассказать. Например, как медведя голыми руками задушил. Хотите послушать?
> скорее наоборот.
Опять-таки, я тоже могу долго рассуждать о тех вещах, о которых не владею достаточной информацией.
>> а я например встречал.
> Ну я тоже могу охотничьих историй рассказать.ты с них и начал
>> А я так вообще этот баг не встречал.
> а я например встречал.Что за дисковый контроллер, какие диски, сколько iops-ов, какой суммарный поток данных при доступе к дискам, какой был паттерн чтения/записи, сколько свободной памяти под pagecache было?
А то, знаете, я то сейчас могу всю память себе забить, вытеснив тем самым кэш, да нагрузить рандомным IO полудохлый ноутбучный диск на 5400. И тоже ведь тормозить начнет!
> Что за дисковый контроллер,уже не важно. если остро интересно - тут отписывался Crazy_Alex-у и ещё раза три...
> какие диски, сколько iops-ов, какой суммарный поток данных при доступе к дискам, какой был паттерн чтения/записи, сколько свободной памяти под pagecache было?
совершенно неважно. речь о том, что после отказа от cciss и перехода на hpsa "потерялись" некоторые контроллеры. контроллеры потом нашлись, но это было потом. а на тот момент была простая ситуация: FreeBSD/DragonflyBSD стали влёт, debian не увидел контроллер и винты. Именно это и имелось в виду, когда я говорил "скорее наоборот". и случай не единичный.
Свежо предание, да верится с трудом.
Как не возмёшь ынырпрайзное железо, так блобы под линух и вантуз таки есть, под бсд нет.
> Признайте уже, что Linux BUG #12309 до сих пор не пофикшен. ;)Этот 12309 как суслик: я его не вижу, но у кого-то он все-таки есть. Правда в основном потому что ламерье вечно пихает все в 1 баг без разбора и потом удивляется когда при починке бага все успокаиваются. О том что это мог быть какой-то иной баг - наивные чукотские изены не догадываются.
> а ведь фряха сливает линю во всех тестах (ось + nginx)А ведь это пишет линуксоид :))
> а ведь фряха сливает линю во всех тестах (ось + nginx)Я так понимаю, дальше первых нескольких графиков (которые в тексте статьи упомянуты как "старое железо") посмотреть терпения не хватило? Ну так посмотри на предпоследний график (для "нового железа"), где на системе с 6 сетевухами FreeBSD выдаёт примерно на треть больше, чем Линукс.
>высокопроизводительного TCP/IP стека, работающей в пространстве пользователя и напрямую взаимодействующей с сетевой картой для отправки пакетовЭталонная реализация взаимоисключающих параграфов
>>высокопроизводительного TCP/IP стека, работающей в пространстве пользователя и напрямую взаимодействующей с сетевой картой для отправки пакетов
> Эталонная реализация взаимоисключающих параграфовВот представь, у тя есть колодец с водой. Задача - обеспечить водоснабжение в колхозе!
Варианты:
1. Пущай сами, кому надо, с ведрами бегают.
2. Качать воду в бочки и всем развозить.
3. Организовать насосную станцию, фильтрацию, развести водопровод, всем установить краны.
4. Динамитом, кирками и лопатами распердолить канал и ручейки до каждого дома.BSD выбрали последний вариант.
А в чем проблема примапать буфер сетевой карты в память процесса? На лялексе так же можно сделать, просто никто не додумался. Алсо, рут получить через эксплоит хрен получится, эта штука вполне может под обычным юзером работать.
> А в чем проблема примапать буфер сетевой карты в память процесса?Прям такой волшебный... Взял и примапил.. :)
А выравниванием, счётчиками, очередью, само как-нить разрулиться.
Х...ня, что маркеры пакетов превратятся в рандом кашу, главное знать слово примапить.
> На лялексе так же можно сделать, просто никто не додумался.Google: kernux, khttps, Tux web-server,...
>> А в чем проблема примапать буфер сетевой карты в память процесса?
> Прям такой волшебный... Взял и примапил.. :)
> А выравниванием, счётчиками, очередью, само как-нить разрулиться.
> Х...ня, что маркеры пакетов превратятся в рандом кашу, главное знать слово примапить.Вместо формирования sk_buff и передачи его netif_receive_skb() в драйвере,
сами расковыриваем весь трафик, обслуживаем ip, tcp логику.Данные передаём
хендлерам. Возможно придётся фронтендом ставить L4, чтоб упрощать навороты транспортного уровня, для передачи упрощённого варианта доморощенному http/tcp серверу.
То есть пишем свою ОС для этого дела? )
userspace network stack? не?
>>> А в чем проблема примапать буфер сетевой карты в память процесса?
>> Прям такой волшебный... Взял и примапил.. :)
>> А выравниванием, счётчиками, очередью, само как-нить разрулиться.
>> Х...ня, что маркеры пакетов превратятся в рандом кашу, главное знать слово примапить.
> Вместо формирования sk_buff и передачи его netif_receive_skb() в драйвере,
> сами расковыриваем весь трафик, обслуживаем ip, tcp логику.Данные передаём
> хендлерам. Возможно придётся фронтендом ставить L4, чтоб упрощать навороты транспортного
> уровня, для передачи упрощённого варианта доморощенному http/tcp серверу.Луиджи же подготовил патчи для linux и даже для ixgbe насколько я ничего не помню -- да там помимо всего мануал -- да и сам патч для сетевых строк в 10.
> Прям такой волшебный... Взял и примапил.. :)Ага, взял и примапил, обычным mmap-ом.
> А выравниванием, счётчиками, очередью, само как-нить разрулиться.
Какие счетчики? Ты мапишь в userspace dma буферы, в которые пишет сетевая карта. Просто бери и разгребай поток ethernet фреймов, по мере поступления. Правда, сделано достаточно дубово, пакеты лежат в буферах по 2К. Но хотелось бы иметь возможность отправлять пакет по кусочкам, например в духе iovec, или вместо фиксированных буферов мапить структуры наподобие ядерных mbuf...
В dpdk пошли еще дальше, мало того, что в userspace замаплены dma буферы, так еще и управление самой картой сделано через uio.
У меня там другие программы, нафига мне разгребать езернет трафик!
Ты не ломая совместимость запихни свою дату в езернет.
А ты думал, халява чтоль... Хе...
Монопольно забрать посебя девайс и его трахать в буфера ещё в детском саду учат.
> У меня там другие программы, нафига мне разгребать езернет трафик!Это у тебя, какое мне до тебя дело? Но задача разгребать 40G+ трафик, как несложно заметить, - довольно специфична и не решается влоб штатными средствами, для того и предназначены всякие dpdk и netmap.
Какие там будут другие программы? Похапе с мускулем что ли?
> Ты не ломая совместимость запихни свою дату в езернет.
Совместимость с чем?
> Монопольно забрать посебя девайс и его трахать в буфера ещё в детском
> саду учат.Ты это intel-у расскажи, а то они, бедолаги, зачем-то понаплодили кода на двести килострок, с lock free буферами, балансировкой нагрузки на ядра... а это, оказывается, детсадовская задача :-D (К слову, большая часть этого код, их же собственные драйвера для FreeBSD)
> На лялексе так же можно сделать, просто никто не додумался.Ну как, никто не додумался? Intel DPDK, PF_RING... Более того, авторы PF_RING и Netmap знакомы друг с другом.
А ведь был когда-то вебсервер, который в ядро был запилен. Tux назывался.
Ну вот, а нынче все на systemd ругаются...
Поинт в "был когда-то". А так - ничто не ново под луной, да.
Какой там дистрибутив Linux?
Забавные люди.
Надо было сравнивать не с обычным линуксовым вебсервером, а с тем, который в ядре уже давно -- khttpd (TUX)
> Надо было сравнивать не с обычным линуксовым вебсервером, а с тем, которыйСкажи спасибо, что они взяли nginx на фре, а не IIS на win-сервере.
> в ядре уже давно -- khttpd (TUX)Это неспортивно! Посмотри на то что с nginx получилось. Он под линухом как-то лучше работает, по поводу чего у некоторых боль пониже спины. Думаешь, им хочется увидеть то же самое еще раз, но на уровне ядра? :)
nginx изнаально написан под FreeBSD
Так это самое смешное
> nginx изнаально написан под FreeBSDИменно поэтому то что наблюдается на этих графиках - полный эпикфэйл FBSD. Их ядро работает настолько галимо, что даже упомянутое читерство им не помогло...
>> nginx изнаально написан под FreeBSD
> Именно поэтому то что наблюдается на этих графиках - полный эпикфэйл FBSD.
> Их ядро работает настолько галимо, что даже упомянутое читерство им не
> помогло...Fig №5. Более мощная отдача при большей загрузке ЦПУ: 6 сетевухах эпик вин. на одной сетевухе "завал" графика на меньшем числе соединений (меньше соединений - меньше отдача). Планка *одинаковая*. Где эпик фейл - неясно.
что характерно, минусы влепили, а возразить нечего :)))
> Посмотри на то что с nginx получилось. Он под линухом
> как-то лучше работает, по поводу чего у некоторых боль
> пониже спины.Ага, на современном оборудовании с 6 сетевухами FreeBSD оказалась всего на треть лучше Линукса, а не в три раза! Действительно, какой ужасный провал! Но вам есть чем гордится - на старом железе Линукс всё же выигрывает. :-)
Ну, и зачем это все? Пришло время пилить экзоядро!
> Ну, и зачем это все? Пришло время пилить экзоядро!Пилите, Шура, пилите. Они золотые.
Разнообразное тестирование и эксперименты - это очень хорошо, позволяет взглянуть на текущее положение дел под разными углами.«Пастернака не читал, но рассуждаю» - это про комментаторов.
Меня в отчете заинтересовало:
Interestingly, we have experienced a collapse on Linux with six NICs.Google Translate:
Интересно, что мы пережили крах на Linux с шестью сетевыми картами.
Жду http на ASIC и FPGA.
> Жду http на ASIC и FPGA.Зачем ждать?! У Шигорина запас кт315 -ых. Он отсыпет! :>
А уменя П2, МП13 и МП42Б были, надо поискать.
МП42Б круче 315-х
а то у них проблема в том что ножки отваливаются, "на скрутках" не соберёшь.
> а то у них проблема в том что ножки отваливаются, "на скрутках"
> не соберёшь.скрутки - вчерашний день. надо делать на wago
Ждем CMS на ASIC и FPGA.
> Ждем CMS на ASIC и FPGA.Memcached на FPGA уже сделали. Только получается дороже, чем на CPU.
FreeBSD всех сделала по поеданию процессора ;)
Ага, а Linux не справился с шестью сетевыми картами. ;)
> Ага, а Linux не справился с шестью сетевыми картами. ;)Только вот зачем на веб-сервере 6 сетевых карт - совершенно непонятно.
> Только вот зачем на веб-сервере 6 сетевых карт - совершенно непонятно.netflix-овцы утверждают что у них 2x10Gb уже боевая конфигурация, а 4x10Gb - тестовая.
И это ethernet а не IB
Чушь полная. "Легковесный" = "урезанная функциональность" - кому это нужно?
С таким же успехом можно "обогнать" ext4, просто тупо копируя данные в сектора. Любые. :)) Эти оптимизации - хрень на постном масле, чисто хакерские развлекушки.Если уж браться за дело, так нужно перетряхнуть этот тухлый TCP стек и переписать под современные нужды - чтобы, например, можно было делать соединение client-NAT<->NAT-client напрямую. Или широковещательные пакеты (чтобы они разветвлялись по мере достижения цели). Или lightweight соединения (среднее между UDP и TCP), которые с одной стороны обеспечивают целостность пересылки, а с другой - не требуют постоянной перепосылки пакетов, не держат соединение и не душат канал всякими проверками, ACK'ами и т.п. Для современного Web'а было бы самое оно.
> и переписать под современные нужды - чтобы, например, можно было делать
> соединение client-NAT<->NAT-client напрямую.NAT? Современные? o_O
Стандартный стек, наверное, так можно дотюнить под нужный паттерн использоваться вместе с тюнингом сервера, без совсем хардкорных патчей кода. Единственный профит от TCP в юзерспейсе это меньше контекст свитчей, больше профита нет. Далее начинаются одни ПЦы - неправильная(неполная) поддержка протокола приводящая к трудно воспроизводимым багам типа внезапного "залипания" соединения, обрывов и т.п.
Смотрю на первый график.
Concurrent Connections 10... 20... 50... 80...
На 10-гиговой сетевухе?
Are you serious?
Так и вижу - сидят 80 мега серферов и быстро-быстро открывают странички с кучей мелкой статики :)
Отдача мелкой статики на _таких_ скоростях подразумевает тысячи одновременных коннектов с относительно небольшой скоростью скачивания.
Как мы видим, чем больше коннектов, тем меньше профита от их программы.Вообще ребята "молодцы".
Что-то написали, придумали себе синтетических тестов и всех в них побили.
Ура, мы первые в скачках на сферических конях!
Пока не вижу профита, который бы перекрыл стоимость изучения и внедрения на продакшене.P.S.
Почему-то нет сравнения с веб сервером G-WAN, который именно по отдаче мелкой статики рвет все и вся.
> G-WAN, который именно по отдаче мелкой статики рвет все и вся.Исключительно в фантазиях его автора. Тестировали, знаем.
Скачать где ?
> Скачать где ?Код Sandstorm очень сырой, даже если его опубликуют, то в production его использовать скорее всего будет нельзя.
Это научная работа - демонстрация того, что используя данный метод можно сделать высокопроизовдительный сервер.
Ну написать софт пригодный для production это работа на несколько лет для одного программиста (или немного меньше для команды из N-человек).
