Группа китайских разработчиков высоконагруженных систем открыла наработки проекта Fastsocket (https://github.com/fastos/fastsocket), в рамках которого подготовлена альтернативная реализация сокетов и сетевой подсистемы ядра Linux. В отличие от штатной сетевой подсистемы ядра, Fastsocket обеспечивает практически линейную масштабируемость, что позволяет добиться существенно более высокой производительности на многоядерных компьютерах. Система является стабильной и хорошо зарекомендовала себя в промышленном использовании. В частности, Fastsocket используется для обеспечения работы online-службы SINA (https://ru.wikipedia.org/wiki/Sina_Corp) (17-й по посещаемости сайт в мире). Все наработки проекта поставляются под лицензией GPLv2.
Fastsocket бесшовно интергрируется с существующими серверными приложениями - достаточно через LD_PRELOAD загрузить библиотеку libfsocket.so, которая подменит собой традиционные функции работы с сокетами. Например, для использования Fastsocket в nginx достаточно запустить сервер командой "LD_PRELOAD=./libfsocket.so nginx". При этом включение поддержки Fastsocket в ядре сопряжено с некоторыми трудностями - для применения Fastsocket следует использовать специально подготовленную отдельную сборку ядра Linux, вместо штатного ядра из дистрибутива. В настоящее время предлагается вариант ядра 2.6.32-431.17.1.el6 для использования в RHEL/CentOS 6.5.
Но игра стоит свеч, на сервере с 24 ядрами CPU рост производительности при выполнении Nginx и Haproxy составляет 290% и 620%, по сравнению с обычным сетевым стеком, предоставляемым ядром из состава CentOS-6.5. Более того, Fastsocket обеспечивает дополнительный прирост производительности при использовании Hyper-Threading и Flow-Director. В частности, активация Hyper-Threading даёт прирост в 20% производительности, а использование сетевой карты на базе контроллера Intel 82599 прибавляет 15% при работе в роли прокси.
<center><a href="https://raw.githubusercontent.com/fastos/fastsocket/master/i... src="http://www.opennet.me/opennews/pics_base/0_1414003226.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://raw.githubusercontent.com/fastos/fastsocket/master/i... src="http://www.opennet.me/opennews/pics_base/0_1414003182.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>URL: https://news.ycombinator.com/item?id=8492867
Новость: http://www.opennet.me/opennews/art.shtml?num=40907
Надеюсь, это скоро будет в ванильном ядре.
>Группа китайских разработчиков...GPLv2Я китайский бы выучил только за то, что им разговаривает "Группа китайских разработчиков..."
Вру на самом деле. Не буду я учить китайский. Я просто хотел сказать -- молодцы.
> Не буду я учить китайский.А куда ты денешься?
А никуда. Китайцы на США и прочих работают и поэтому сносно шпрехают на инглише.
Это откуда такая информация?
Насколько я могу судить по своему опыту общения с китайцами - к английскому у них довольно прохладное отношение.
Даже приезжающие в Рф студенты не торопятся учить англ., а уровень подготовки большинства из них даже ниже, чем у выпускников России.
В приграничных районах (манджурия) - китайцы более сносно говорят на русском, чем на английском.
Так что на счет "сносно шпрехают" - боооольшой вопрос, они в плане интеграции самодостаточны.
Маньчжурия
> Это откуда такая информация?От всевозможных китайских конторок. Если они хотят что-то за пределами китая продавать - они неизбежно шпрехают на инглише.
> Так что на счет "сносно шпрехают" - боооольшой вопрос,
Сравни английскую версию хоть того же алиэкспресса и русскую. Особенно перевод описаний товаров. Говорит само за себя.
А как там шпрехают китайские крестьяне - только им и интересно. Они ни на что не влияют с точки зрения глобальных процессов которые могут меня как-то зацепить.
>> Это откуда такая информация?
> От всевозможных китайских конторок. Если они хотят что-то за пределами китая продавать
> - они неизбежно шпрехают на инглише.Это те, кто работают с англоговорящими партнерами.
На дальнем востоке, на китайских рынках сидят китайцы, которые сносно говорят по русски (правда, не все).> А как там шпрехают китайские крестьяне - только им и интересно. Они ни на что не влияют с точки зрения глобальных процессов которые могут меня как-то зацепить.
Как будто вас сейчас сильно цепляют глобальные процессы.
>Это те, кто работают с англоговорящими партнерами.Так они при этом и с русскими партнерами на английском шпрехают.
Дык,английский - и проще учится и толку больше
Гораздо интереснее, насколько оно устойчиво к SYN-флуду, а также к большому количеству полузакрытых соединений.
Думаю, что SINA флудят и DDoS-ят не меньше, чем Twitter.
> DDoS-ят не меньше, чем Twitter.Как можно ддосить сервер для ддоса?
Это не сервер для ддоса, а средство информационной войны
> Думаю, что SINA флудят и DDoS-ят не меньше, чем Twitter.чотко!!!
Ох, надеюсь без бэкдоров и зондов
> Ох, надеюсь без бэкдоров и зондовСырцы есть, проверяй.
Сколько тебе заплатить, чтобы ты проверил?
Могу я проверять, за регулярную почасовую оплату, на полную ставку, обещать правда могу только то что буду честно работать, и изучать вопрос...
Нет столько денег. Вернее нет технологий чтоб пересадить ему мозги разработчика сабжа.
> Сколько тебе заплатить, чтобы ты проверил?прим. 250000$ за O(x^n) анализ.
Более сложные методы после первого этапа по договорённости.Иль опять, чиста попистить?
> Ох, надеюсь без бэкдоров и зондов...
"LD_PRELOAD=./libfsocket.so nginx".
Здравствуйте. Я китайский бэкдор. В силу плохого уровня развития IT в нашей стране мы умеем только копипастить, поэтому пожалуйста сами пропишите наш руткит в автозагрузку вашим программам и пришлите ссылку вашим друзьям.
Это конечно иронизирую.Кстати могу ошибаться, но LD_PRELOAD будет проблемно использовать в x86_64 без плясок.
Вообще да, LD_PRELOAD это еще та дырища.
> LD_PRELOAD будет проблемно использовать в x86_64 без плясок.Расскажите мне - в чем у меня проблемы на x86_64? А то я их не заметил :).
> Вообще да, LD_PRELOAD это еще та дырища.
Скорее, полухакерская технология, которая обычно используется разработчиками, исследователями-экспериментаторами и просто взломщиками, нежели как какое-то продакшновое решение.
>> LD_PRELOAD будет проблемно использовать в x86_64 без плясок.
> Расскажите мне - в чем у меня проблемы на x86_64? А то
> я их не заметил :).
>> Вообще да, LD_PRELOAD это еще та дырища.
> Скорее, полухакерская технология, которая обычно используется разработчиками, исследователями-экспериментаторами
> и просто взломщиками, нежели как какое-то продакшновое решение.Попробуйте запустить примеры из статьи в x86_64:
http://fluxius.handgrep.se/2011/10/31/the-magic-of-ld_preloa.../
Я попробовал свой код. Пашет. Мало ли откуда у того автора примеров руки...
> Я попробовал свой код. Пашет. Мало ли откуда у того автора примеров
> руки...Там ничего опасного нет в принципе. Я тоже его пробовал в качестве примера работы с LD_PRELOAD в генте AMD x86_64 К сожалению этот пример не удалось заставить работать. Несмотря что код пример красив и остальное. Похожий код для x86 профиля архитектуры, работает без проблем (на примере патча libcwait - там несколько строчек всего подгружаются по LD_PRELOAD)
>> Я попробовал свой код. Пашет. Мало ли откуда у того автора примеров
>> руки...
> Там ничего опасного нет в принципе. Я тоже его пробовал в качестве
> примера работы с LD_PRELOAD в генте AMD x86_64 К сожалению этот
> пример не удалось заставить работать. Несмотря что код пример красив и
> остальное. Похожий код для x86 профиля архитектуры, работает без проблем (на
> примере патча libcwait - там несколько строчек всего подгружаются по LD_PRELOAD)mk.;
>>> Я попробовал свой код. Пашет. Мало ли откуда у того автора примеров
>>> руки...
>> Там ничего опасного нет в принципе. Я тоже его пробовал в качестве
>> примера работы с LD_PRELOAD в генте AMD x86_64 К сожалению этот
>> пример не удалось заставить работать. Несмотря что код пример красив и
>> остальное. Похожий код для x86 профиля архитектуры, работает без проблем (на
>> примере патча libcwait - там несколько строчек всего подгружаются по LD_PRELOAD)
> mk.;?
>> mk.;
> ?хрен его знает. на Plan9 похоже, билдит что-то там. но зачем он этим на форуме хвастается — не ясно. да и не Plan9, пробелы не поставлены.
>>> mk.;
>> ?
> хрен его знает. на Plan9 похоже, билдит что-то там. но зачем он
> этим на форуме хвастается — не ясно. да и не Plan9,
> пробелы не поставлены.LD_PRELOAD актуально для p9 ???
> LD_PRELOAD актуально для p9 ???mk актуально.
>> LD_PRELOAD актуально для p9 ???
> mk актуально.mk не приходилось использовать
>>> LD_PRELOAD актуально для p9 ???
>> mk актуально.
> mk не приходилось использоватьесли вдруг у тебя в проектах где-то есть make, и это не автокраповский выхлоп — попробуй. может понравиться. и rc в качестве шелла попробуй, тоже может понравиться.
>>>> LD_PRELOAD актуально для p9 ???
>>> mk актуально.
>> mk не приходилось использовать
> если вдруг у тебя в проектах где-то есть make, и это не
> автокраповский выхлоп — попробуй. может понравиться. и rc в качестве шелла
> попробуй, тоже может понравиться.make вполне устраивает
rc в моем дистро - это утилита для запуска сервисов, а так стандартно: bash
Какое отношение эти программы имеют к LD_PRELOAD ?
> Какое отношение эти программы имеют к LD_PRELOAD ?а я откуда знаю?
> Вообще да, LD_PRELOAD это еще та дырища.а возможность запускать программы — вообще мегадырка.
Особенно под рутом)
сначала ждем пока что-то появится, потом пока это проверят, потом пока обкатают, еще чуть-чуть ждём откровений сбежавших агентов или подозрительных некрологов, на закате технологии начинаем нерешительно пробовать.
Ура, я наконец понял в чём на самом деле была проблема высоконагруженных систем. А то по глупости всё грешил на базы данных, тормоза динамических языков программирования и шифрование SSL.
Не, бд и ссл действительно тормоза.Для бд рулит кастомная группировка данных, когда одним запросом подгружается всё связанное
> А то по глупости всё грешил на базы данных, тормоза
> динамических языков программирования и шифрование SSL.Ты не понял. Упомянутое становится проблемой, когда все предыдущие вещи уже разрулили :).
> всё грешил на базы данных,В большинстве случаев это решается правильной организацией кэширования.
Да, подчас очень непростой, но таки решается.> тормоза динамических языков программирования
Динамический язык динамическому языку рознь. LuaJIT, например, тормозами не страдает.
Кстати, ngx_lua и базирующийся на нём OpenResty - тоже китайского происхождения.> и шифрование SSL.
Которое, во-первых, можно использовать только для авторизации, после чего возвращаться к http, во-вторых, большую часть оверхеда можно переложить на CDN, пользуясь тем что основной оверхед приходится на handshake.
Кеширование это моветон. Им можно решить только задачи с преимущественным чтнением данных. А щас интерктив везде, чтение запись выравниваются
> Кеширование это моветон.Весьма неожиданная точка зрения, надо признать.
> Им можно решить только задачи с преимущественным чтнением данных.
> А щас интерктив везде, чтение запись выравниваютсяВас не затруднит привести пару-тройку примеров из современного веб?
А также пояснить в чем принципиальное затруднение в решении этой проблемы Write-back кэшированием.
> Кеширование это моветон. Им можно решить только задачи с преимущественным чтнением данных.
> А щас интерктив везде, чтение запись выравниваютсяКакое выравнивание? checkbox от кнопки "like" сопоставим по объёму с выгрузкой статьи?
Просто представьте что вы на посещаемых сайтах пишете примерно столько-же слов сколько читаете.
> В большинстве случаев это решается правильной организацией кэширования.Или использованием каких-нибудь NoSQL баз и простых схем данных. Они быстрые как понос при правильном подходе.
> Динамический язык динамическому языку рознь. LuaJIT, например, тормозами не страдает.
Если уж на то пошло, грузить бэкэнд выполнением скриптов на каждого юзера - тоже моветон: nginx может кэшировать все в статику и отдавать как просто статичные файлы. А при отдаче статики и кэшированного контента уже все может упереться в упомянутые эффекты.
> большую часть оверхеда можно переложить на CDN,
CDN вообще-то желают бабла за свои услуги. И видимо остаются в наваре от этой деятельности, что прозрачно намекает что самому хостить несколько выгоднее, особенно при больших масштабах. Было бы это не так - ну не работали бы CDN себе же в убыток?!
> NoSQL баз и простых схем данных.
> Они быстрые как понос при правильном подходе.Какие образные у вас сравнения. Намекаете на то что MongoDB медленней PostgreSQL? Мы в курсе.
> Если уж на то пошло, грузить бэкэнд выполнением скриптов на каждого юзера - тоже моветон
Действительно, давайте каждого юзера называть просто Васей, они всё равно одинаковые практически, юзеры эти.
> CDN вообще-то желают бабла за свои услуги
Ужас какой, действительно. Все остальные-то компоненты высоконагруженных систем обычно совершенно ничего не стоят.
Не стоит "правильность" обеспечивать кэшированием. Смотри глубже - ленивая, отложенная загрузка и еще кое-что (сходно с тяжелой графикой)
шардинг
>большую часть оверхеда можно переложить на CDNRob - подумай такую мысль: это для CDN-щиков и сделано :) Как вариант. Оне же тоже люди и им тоже хочеЦЦо накладные придавить вниз. Ы?
Так прямым же текстом написано - кем сделано и для кого. SINA, для себя и своих сервисов.
А полезно будет всем, на то и СПО.
А к конкретно CDN-щикам какое-то странное, кажется, тут отношение - как к кровавым капиталистам-эксплуататорам, с чего б?
> А к конкретно CDN-щикам какое-то странное, кажется, тут отношение - как к
> кровавым капиталистам-эксплуататорам, с чего б?потому что они такие и есть, например — не из альтруизма же работают? а во-вторых, и просто дебилы.
> потому что они такие и есть, например — не из альтруизма же
> работают?Кто-то заставляет им платить и пользоваться их услугами?
Городите себе на коленке своё, никто не мешает.
Только ваш же Энгельс бенефиты разделения труда еще век назад подробно разобрал.
> Кто-то заставляет им платить и пользоваться их услугами?
> Городите себе на коленке своё, никто не мешает.
> Только ваш же Энгельс бенефиты разделения труда еще век назад подробно разобрал.каким образом это отменяет то, что я написал? и каким образом оно вообще связано одно с другим?
>Так прямым же текстом написано - кем сделано и для кого. SINA, для себя и своих сервисов.А Линус воотбще эмулятор терминала писал, а оно вона как вывернуло :)
>А полезно будет всем, на то и СПО.
Хотелось бы верить. Скорей всего - да. Вспомни какой был восторг когда научили стэк все ОБА проца пользовать :) Потом начало расти. Это просто этап убора шершавостей на количестве ядер больше N :)
>А к конкретно CDN-щикам какое-то странное, кажется, тут отношение - как к кровавым капиталистам-эксплуататорам, с чего б?
А я - знаю? Я вот сам себе CDN лепил дык вылезло как раз вот это. Баз то нету, скриптов - нету, а всё что есть - на сторидже, в статике и надо это слить в сокеты(Ы) макс быстро и с мин. задержкой. Ну и смотри бенефиты топика :)
> Баз то нету, скриптов - нету, а всё что есть - на сторидже, в статике и надо это слить в сокеты(Ы) макс быстро и с мин. задержкойТогда первым делом ядро надо с пути убрать.
DPDK, pf_ring, еще несколько менее популярных вариантов.
А почему с ядром 2.6 сравнивают?
чтобы 620% прироста показать.
как-то так получилось, что сетевой стек на последующих версиях ядра, оказался тормознее... этот вопрос уж не одну сотню раз всплывал на различных форумах.
а по картинкам этого не видно
Это не совсем так, были регрессии, но они правились.
В ядре rhel/centos 6 от 2.6 осталась только совместимость, очень многое полезное из 3.х туда бекпортировано.
> В ядре rhel/centos 6 от 2.6 осталась только совместимость,Нет
Сравнивают со стандартным де-факто ядром - то есть текущим редхатовским.
> Сравнивают со стандартным де-факто ядром - то есть текущим редхатовским.Т.е. с 3.10 из RHEL7 ?
Это станет стандартом еще через пару лет. Никто в здравом уме не мигрирует, если этого можно не делать. А у редхата можно не мигрировать очень долго.
нудк HPC-же.
а там у китайцев наряду с LFS, Калькой, Центос - самое популярное с производными.
солидный прирост.
я знал что в "родном" стэке полно барахла на скотче и соплях, держащегося, но не думал что НАСТОЛЬКО много.
Полное представление о том НАСКОЛЬКО даёт DPDK, например - когда сотни тысяч conn/s превращаются вдруг в полтора десятка миллионов, на том же железе.
потрясно. на этом всем еще и фреймворк сетевой забабахать.
пошустрее ковбоя на эрлан чтонить высокомасштабируемое.
А нижние графики-то --- похоже, фальшивка: таких _в мелких деталях_ самоподобных кривых _за сутки_ хрен получишь.
Из описания в Википедии "Sina Corp — китайская интернет-компания. Является сетью общения между китайскими диаспорами по всему миру. Имеет четыре направления деятельности: Sina Weibo, Sina Mobile, Sina Online, и Sina.net. Объединяет более 100 миллионов пользователей по всему миру"
Какая-то массоновская секта!
масонов еще не было, а китайцы - были.
однако.
> масонов еще не было, а китайцы - были.Вот мы их и раскусили :).
>> масонов еще не было, а китайцы - были.
> Вот мы их и раскусили :).ато!
все масоны - скрытые киитайцы.
искусно прячущие фирменный искосый взгляд, под полой плащей(голову туда засунув, аки лебедь).
Китайцы довольно агрессивно пытаются пропихнуть свои дырки в другие страны, как я погляжу. Офис кривой, теперь вот это...
теперь ждем соизмеримые наработки наших ученых, а то все чего то там выбирают выбирают, видать ни как не могут выбрать =D
у российских чиновников от науки на уме только распил бюджетных денег
это был сарказм про физиков и слаку ...
> теперь ждем соизмеримые наработки наших ученых, а то все чего то там
> выбирают выбирают, видать ни как не могут выбрать =DУчёным сетевые стеки реализовывать угу, это ключевая проблема человечества...
> Учёным сетевые стеки реализовывать угу, это ключевая проблема человечества...а что им следует делать? расскажи, пожалуйста, очень интересно.
все лучше чем латать убожество, сделаное до них руко-[cenzored]ами.
более продуктивно.
и куда более ресурсоемко, чем вагон апликухи им пытаться наваять, поручать.
А вот как раз скоро конференция будет, сходите, много интересного увидите.
http://sdiconf.com/rus/
Хы, это как же его до китайцев писали? Видать, Телса мало Алана по рукам била.
трэш жестокий на первый взгляд:
int __netif_receive_skb(struct sk_buff *skb)
...
3382
null_or_bond = NULL;
if ((skb->dev->priv_flags & IFF_802_1Q_VLAN) &&
(vlan_dev_real_dev(skb->dev)->priv_flags & IFF_BONDING)) {
null_or_bond = vlan_dev_real_dev(skb->dev);
}не ну молодцы парни, драйвер специфику в dev.c -то засунуть, а? люди медленно проходят в двери? снесем двери нах!
>[оверквотинг удален]
> int __netif_receive_skb(struct sk_buff *skb)
> ...
> 3382
> null_or_bond = NULL;
> if ((skb->dev->priv_flags & IFF_802_1Q_VLAN) &&
> (vlan_dev_real_dev(skb->dev)->priv_flags & IFF_BONDING)) {
> null_or_bond = vlan_dev_real_dev(skb->dev);
> }
> не ну молодцы парни, драйвер специфику в dev.c -то засунуть, а? люди
> медленно проходят в двери? снесем двери нах!Сделаем рядом вторую, будет 2 потока, а так же небольшое количество отсеявшихся, тех кто в перегородку между дверьми попал...
>[оверквотинг удален]
> int __netif_receive_skb(struct sk_buff *skb)
> ...
> 3382
> null_or_bond = NULL;
> if ((skb->dev->priv_flags & IFF_802_1Q_VLAN) &&
> (vlan_dev_real_dev(skb->dev)->priv_flags & IFF_BONDING)) {
> null_or_bond = vlan_dev_real_dev(skb->dev);
> }
> не ну молодцы парни, драйвер специфику в dev.c -то засунуть, а? люди
> медленно проходят в двери? снесем двери нах!Здесь нет никакой драйвер специфики.
__netif_receive_skb API сетевого стека, например, используется во всех
сетевых драйверах, при реализиции метода механизма napi polling (struct napi_struct { .poll() }),
в которых эта функция вызывается для выполнения обработки стека протоколов в пакете.vlan_dev_real_dev - относится к API системы реализации vlan-ов, отделена от конкретных
драйверов.
> __netif_receive_skb API сетевого стека, например, используется во всехсетевых драйверах при реализиции метода механизма napi polling (struct napi_struct { .poll() }),
....
да она как-бы вообще при обработке любого skb используется, очень "полезная" функция! :-D
вот только ..._skb_core им чем-то не понравилась, выпилил они ее. Ну что, художники, так
они мир видят.> Здесь нет никакой драйвер специфики.
правда, правда? а bonding здесь что делает?
поищи по ключевым словам master/slave/bond, весьма доставляет! bond теперь часть core.
специфики vlan девайсов i.e. IFF_802_1Q_VLAN там, кстати, в дев никогда не было.
О! и протокольные - там-же. netif_direct_tcp там-же в dev.с, как тебе?
не, нынешний netdev team тоже такие вещи иногда творит от безысходности, но ну что
куда деть tcp офлоад? но эти парни похоже решили, что безысходность - это и есть
наш путь. :)
нудк "костыльная реализация" Китайцами была забацана для внутреннего, in-house применения. если народу понравится как работает и бенефиты - напишут более пряморукую реализацию сабжа.
было бы желание.
а при таком профите/бустре от - только у совсем ленивых ИТ-шников оно не появится.
>следует использовать специально подготовленную отдельную сборкуОх уж эти китайцы! Не могут без костылей.
Т.е. сейчас у них есть патч только для ядра 2.6.32 (которому скоро будет 5 лет).
И надо выбирать - или ставить старое патченное, или ждать патча для нового ядра.
Судя по графикам, я могу сделать и другой вывод.
Для приемлемого быстродействия достаточно просто обновиться до 3.13.
И отпадет огромный объем работы.
в 3.14 улучшения относительно 2.6.3х ~ в районе десятков процентов(трех примерно) а тут речь о нескольких СОТНЯХ разницы, причем чем толще(в ядрах и ТЧ)система, тем Выпуклее бенефиты от.
мораль: лучше совместить профит ОБОИХ подходов. портировать на новое ядро и радоваться жизни.
> в 3.14 улучшения относительно 2.6.3х ~ в районе десятков процентов(трех примерно) а
> тут речь о нескольких СОТНЯХ разницы, причем чем толще(в ядрах и
> ТЧ)система, тем Выпуклее бенефиты от.
> мораль: лучше совместить профит ОБОИХ подходов. портировать на новое ядро и радоваться
> жизни.Я говорю про приведенные графики:
http://www.opennet.me/opennews/pics_base/0_1414003226.png
