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

я это проходил ещё когда надеялся на пакеты в дистрибутиве =)

Кстати, есть забавный и эффективный хак: всё чтение с диска унести в nginx

я просто дергаю по http через bytes-range и проксирую клиенту.

нет, это не имеет никакого смысла

эрланг читает с диска так же эффективно как и nginx

но как можно специально выбрать другую фс.. типа а нам удобней btrfs или там fat32 чтоли

да-да, fat32 это тема

но в целом мы справляемся с 20-гигабитной раздачей и без таких специальных мер

эрланг читает с диска так же эффективно как и nginx

нет. в nginx есть aio, кеш открытых файлов, sendfile и куча модулей из коробки.

ага, поэтому в свежем nginx ведется активная работа по переделке чтения диска на ту же схему пулов тредов, которая есть в эрланге

ага, поэтому в свежем nginx ведется активная работа по переделке чтения диска на ту же схему пулов тредов, которая есть в эрланге

пул тредов - это один из вариантов.

и они его уже сделали :)

sendfile вообще сомнительная штука, схлопотать неконтролируемый лок на диск без шансов что-то сделать

хуже только mmap

кеш открытых файлов вообще не имеет никакого отношения к ядру эрланга

sendfile вообще сомнительная штука, схлопотать неконтролируемый лок на диск без шансов что-то сделать

ну так пул тредов и вот это всё.

и по треду на клиента, а клиентов 15 тыс

хуже только mmap

нет. mmap - это хорошо, если в сочетании с madvise + mincore.

ну и с mmap можно использовать zero copy :)

да, я слышал это мнение

и по треду на клиента, а клиентов 15 тыс

ну вот зачем глупости писать? пулу тредов пофик что за сисколлы исполнять: open это или sendfile.

вот и у меня вопрос: зачем глупости писать

клиент попросил файл, ему сделали sendfile в отдельном треде

sendfile встал колом из-за диска и сети и на клиента получили отдельный занятый тред

клиент попросил файл, ему сделали sendfile в отдельном треде

ну так у тебя расходы - это оверхед от пула тредов + время сисколла.

sendfile встал колом из-за диска и сети и на клиента получили отдельный занятый тред

у тебя так же встанет колом на open/read/stat

на то же время.

но твой sendfile встанет колом на сетевую операцию

но твой sendfile встанет колом на сетевую операцию

нет. он встанет колом на время поднятия страничек с диска. короче, пока bio отработает.

и всё то, ради чего делали event архитектуру идет лесом, потому что один модемный пользователь забирает себе тред

и всё то, ради чего делали event архитектуру идет лесом, потому что один модемный пользователь забирает себе тред

он у тебя будет забирать и так на чтении.

смотри: sendfile отдаёт странички из page cache

если у тебя нужных страничек нет, то ты залипнешь на время поднятия их с диска.

без разницы, что вызвало cache miss.

в freebsd сделали хак: SF_NODISKIO - если страничек нужных нет, то посигналить и вернуть управление.

с mmap ты можешь позвать mincore и он тебе расскажет, что есть в кеше, а чего нет.

соответственно, можно позвать madvise с MADV_WILLNEED и ядро асинхронно(!) подтянет эти странички в кеш.

беда в отсутствии механизма нотификации о том что всё завершилось.

nginx для этого на freebsd использовал сайд-эффект aio: читаешь 1 байт, а тебе в кеш подтягивается блок размером с окно readahead.

вообщем, io - боль.

это всё классно и весело, но нам почти всегда надо данные обрабатывать прежде чем отдать клиенту, поэтому всё равно надо прочесть

pread + write дает без особых проблем устойчивые 10 гигабит не загружая полностью современный процессор, так что все попрыгивания на левом ухе, специфичные для конкретного билда ОС может и могут что-то добавить, но нам это просто не нужно

а freebsd мы не рассматриваем

pread + write дает без особых проблем устойчивые 10 гигабит не загружая полностью современный процессор, так что все попрыгивания на левом ухе, специфичные для конкретного билда ОС может и могут что-то добавить, но нам это просто не нужно

preadv + vmsplice? :)

простой колхозный read с диска в треде и обычный write в сокет как это сделано в эрланге (буфер, epoll и все такое)

т.е. все эти исхищрения нужны когда хочется 40 и больше распихать

у нас нет клиентов с 40 гигабитами, только 20 максимум, но по опыту тех же однокласников, для 40 гигабит тоже не нужны все эти премудрости: просто read/write справляются

так что наверное это нужно либо когда хочется что-то ещё запустить на том же сервере, либо когда уже цель в 100G

так что наверное это нужно либо когда хочется что-то ещё запустить на том же сервере, либо когда уже цель в 100G

это нужно когда у тебя есть желание очень скромно использовать ресурсы. например, жить на ssd-cached openvz/kvm

мне кажется, что сейчас ты уже придумываешь, потому что только что ты рассказывал про freebsd, а потом перешел на openvz

мне кажется, что сейчас ты уже придумываешь, потому что только что ты рассказывал про freebsd, а потом перешел на openvz

я лишь рассказал как у соседей сделано :)

да, я понимаю. Я знаю что люди любят сложные решения =)

среди программистов mail.ru я неоднократно встречал такое мнение, что в продакшне нельзя пользоваться маллоком, потому что он нещадно тормозит

у нас нет клиентов с 40 гигабитами, только 20 максимум, но по опыту тех же однокласников, для 40 гигабит тоже не нужны все эти премудрости: просто read/write справляются

ну вот у одного из твоих кастомеров заходишь на сервер - а там флюссоник жрёт 400-600% cpu.

и чего?

во-первых, флюссоник делает дохрена чего ещё, во-вторых главное что бы справлялся

ну и рядом больше ничего не запустишь. потому что тогда клиенты начинают страдать

а не надо ничего запускать на сервере, который вещает видео

во-первых, флюссоник делает дохрена чего ещё, во-вторых главное что бы справлялся

а ты запусти perf top -p flussonic_pid и скажи что там будет в первых 5 строчках )

а не надо ничего запускать на сервере, который вещает видео

ну вот странный у тебя подход: фс выбирать нельзя, а вот 1 задача - 1 сервер требуешь.

не странный, а рабочий

ты сейчас ведешь к тому, что бы сэкономить 30$ в месяц и вместо отдельного сервера для сайта, запустить и сайт, и вещание на одном сервере

ERROR: S client not available

это типично отечественный инженерный подход: наймите меня за $2000 в месяц, я вам сэкономлю $30 в месяц

ты сейчас ведешь к тому, что бы сэкономить 30$ в месяц и вместо отдельного сервера для сайта, запустить и сайт, и вещание на одном сервере

ну раз ты про деньги, то сколько будет стоит сервер для вещания 10G на флюссонике?

Пипец, чтобы даунгрейдить биос на плате супермикро, пришлось сгенерить лист закачки типа /getfile.php?0000 -> ?9999 c единичным инкрементом. В эти сети уже попались редкие архивные варианты (:

И подход ещё не переносим и не повторяем, приходит следующий за 3000$ и переделывает на фрибсд

Так и живем

это типично отечественный инженерный подход: наймите меня за $2000 в месяц, я вам сэкономлю $30 в месяц

это единственно рабочий. когда у клиента будет тупить дисковый io или ещё какая-то веселая проблема производительности что вы делать будете? :)

ты мне сейчас хочешь рассказать слезную историю о том, что наш флюссоник жрет очень много ресурсов и требует дорого железа, а вот какой-то софт, про который тебе рассказывали, запускается на арме от скейлвей и раздает 10G за 5 баксов в месяц

не хочу тебя расстраивать, но никаких особых хитростей тут нет. Я тебе ещё раз рекомендую посмотреть на опыт однокласников, которые просто правильным инженерным решением с помощью обычной явы раздают 40G с коробки

ты мне сейчас хочешь рассказать слезную историю о том, что наш флюссоник жрет очень много ресурсов и требует дорого железа, а вот какой-то софт, про который тебе рассказывали, запускается на арме от скейлвей и раздает 10G за 5 баксов в месяц

Я хочу лишь сказать что к меня одна операция копирования роняет производительность в 2 раза.

это очень грубая оценка, которая не отражает реальности

нет способа перегнать с диска в tcp сессию на карте в обход памяти и процессора, а значит всё равно будет передача в общую память и раздача оттуда

не хочу тебя расстраивать, но никаких особых хитростей тут нет. Я тебе ещё раз рекомендую посмотреть на опыт однокласников, которые просто правильным инженерным решением с помощью обычной явы раздают 40G с коробки

Я видел их доклад. Это ж ад и костыли: у них свой кеш в tmpfs

нет способа перегнать с диска в tcp сессию на карте в обход памяти и процессора, а значит всё равно будет передача в общую память и раздача оттуда

Вопрос в том каким способом: dma или же силами cpu

насколько я понимаю, разницы тут между read и всякими спец-штуками не будет, потому что это всё равно все идет к диску сквозь его vfs cache и уже какой-то код внизу просит подогнать данные в память

разница только в том: происходит memcpy из памяти ядра в память процесса или нет

или я неправ?

разница только в том: происходит memcpy из памяти ядра в память процесса или нет

Да. И этот memcpy дорог. На read из файла в процесс и из процесса в сокет 2 копирования. Если ты mmap'нул файл и позвал madvise - это 0 копирований. Если vmsplice + gift pages - это снова 0 копирований, т.к. странички процесса дарятся ядру.

вот мой тезис как раз в том, что это не такая дорогая процедура, как считается

по крайней мере сегодня

Не хочу вас огорчать, дорогие коллеги Но, пока никто из вас флеймграфов не предоставил - это разговор ни о чем

Вы парни сильные, должны с этим справиться

т.е. типа у тебя толще, да?

мы тут пока мило обсуждали, как же данные в сеть пихать, я понял что у кастомера NFS

и видео пишется и читается с NFS

диски, хуиски, dma. Вот оно всё это, да. Я не уверен что запись и трансляция пользователям идет по разным сетевухам

Господа, а что лучше - DMA или MDMA?

Господа, а что лучше - DMA или MDMA?

1:1

Мдма конечно ) смотря для чего

Господа, а что лучше - DMA или MDMA?

Скителс и адреналин раш