« Rev
@devops_ru   180
Fwd »


Magistr
но ведь можно рекомендовать фс
Maksim
можно, но это приведет только к тому, что люди будут выбирать другое принципиально, а мы будем тратить силы на то, что бы ожидать хорошего, а получать не то
Maksim
я это проходил ещё когда надеялся на пакеты в дистрибутиве =)
Roman
Кстати, есть забавный и эффективный хак: всё чтение с диска унести в nginx
Roman
я просто дергаю по http через bytes-range и проксирую клиенту.
Maksim
нет, это не имеет никакого смысла
Maksim
эрланг читает с диска так же эффективно как и nginx
Magistr
но как можно специально выбрать другую фс.. типа а нам удобней btrfs или там fat32 чтоли
Maksim
да-да, fat32 это тема
Maksim
но в целом мы справляемся с 20-гигабитной раздачей и без таких специальных мер
Roman
эрланг читает с диска так же эффективно как и nginx
нет. в nginx есть aio, кеш открытых файлов, sendfile и куча модулей из коробки.
Maksim
ага, поэтому в свежем nginx ведется активная работа по переделке чтения диска на ту же схему пулов тредов, которая есть в эрланге
Roman
и они его уже сделали :)
Maksim
sendfile вообще сомнительная штука, схлопотать неконтролируемый лок на диск без шансов что-то сделать
Maksim
хуже только mmap
Maksim
кеш открытых файлов вообще не имеет никакого отношения к ядру эрланга
Maksim
и по треду на клиента, а клиентов 15 тыс
Roman
хуже только mmap
нет. mmap - это хорошо, если в сочетании с madvise + mincore.
Roman
ну и с mmap можно использовать zero copy :)
Maksim
да, я слышал это мнение
Roman
и по треду на клиента, а клиентов 15 тыс
ну вот зачем глупости писать? пулу тредов пофик что за сисколлы исполнять: open это или sendfile.
Maksim
вот и у меня вопрос: зачем глупости писать
Maksim
клиент попросил файл, ему сделали sendfile в отдельном треде
Maksim
sendfile встал колом из-за диска и сети и на клиента получили отдельный занятый тред
Roman
клиент попросил файл, ему сделали sendfile в отдельном треде
ну так у тебя расходы - это оверхед от пула тредов + время сисколла.
Roman
на то же время.
Maksim
но твой sendfile встанет колом на сетевую операцию
Roman
но твой sendfile встанет колом на сетевую операцию
нет. он встанет колом на время поднятия страничек с диска. короче, пока bio отработает.
Maksim
и всё то, ради чего делали event архитектуру идет лесом, потому что один модемный пользователь забирает себе тред
Roman
смотри: sendfile отдаёт странички из page cache
Roman
если у тебя нужных страничек нет, то ты залипнешь на время поднятия их с диска.
Roman
без разницы, что вызвало cache miss.
Roman
в freebsd сделали хак: SF_NODISKIO - если страничек нужных нет, то посигналить и вернуть управление.
Roman
с mmap ты можешь позвать mincore и он тебе расскажет, что есть в кеше, а чего нет.
Roman
соответственно, можно позвать madvise с MADV_WILLNEED и ядро асинхронно(!) подтянет эти странички в кеш.
Roman
беда в отсутствии механизма нотификации о том что всё завершилось.
Roman
nginx для этого на freebsd использовал сайд-эффект aio: читаешь 1 байт, а тебе в кеш подтягивается блок размером с окно readahead.
Roman
вообщем, io - боль.
Maksim
это всё классно и весело, но нам почти всегда надо данные обрабатывать прежде чем отдать клиенту, поэтому всё равно надо прочесть
Maksim
pread + write дает без особых проблем устойчивые 10 гигабит не загружая полностью современный процессор, так что все попрыгивания на левом ухе, специфичные для конкретного билда ОС может и могут что-то добавить, но нам это просто не нужно
Maksim
а freebsd мы не рассматриваем
Maksim
простой колхозный read с диска в треде и обычный write в сокет как это сделано в эрланге (буфер, epoll и все такое)
Maksim
т.е. все эти исхищрения нужны когда хочется 40 и больше распихать
Maksim
у нас нет клиентов с 40 гигабитами, только 20 максимум, но по опыту тех же однокласников, для 40 гигабит тоже не нужны все эти премудрости: просто read/write справляются
Maksim
так что наверное это нужно либо когда хочется что-то ещё запустить на том же сервере, либо когда уже цель в 100G
Roman
так что наверное это нужно либо когда хочется что-то ещё запустить на том же сервере, либо когда уже цель в 100G
это нужно когда у тебя есть желание очень скромно использовать ресурсы. например, жить на ssd-cached openvz/kvm
Maksim
мне кажется, что сейчас ты уже придумываешь, потому что только что ты рассказывал про freebsd, а потом перешел на openvz
Maksim
да, я понимаю. Я знаю что люди любят сложные решения =)
Maksim
среди программистов mail.ru я неоднократно встречал такое мнение, что в продакшне нельзя пользоваться маллоком, потому что он нещадно тормозит
Maksim
и чего?
Maksim
во-первых, флюссоник делает дохрена чего ещё, во-вторых главное что бы справлялся
Roman
ну и рядом больше ничего не запустишь. потому что тогда клиенты начинают страдать
Maksim
а не надо ничего запускать на сервере, который вещает видео
Roman
во-первых, флюссоник делает дохрена чего ещё, во-вторых главное что бы справлялся
а ты запусти perf top -p flussonic_pid и скажи что там будет в первых 5 строчках )
Roman
а не надо ничего запускать на сервере, который вещает видео
ну вот странный у тебя подход: фс выбирать нельзя, а вот 1 задача - 1 сервер требуешь.
Maksim
не странный, а рабочий
Maksim
ты сейчас ведешь к тому, что бы сэкономить 30$ в месяц и вместо отдельного сервера для сайта, запустить и сайт, и вещание на одном сервере
Maksim
это типично отечественный инженерный подход: наймите меня за $2000 в месяц, я вам сэкономлю $30 в месяц
Алексей
Пипец, чтобы даунгрейдить биос на плате супермикро, пришлось сгенерить лист закачки типа /getfile.php?0000 -> ?9999 c единичным инкрементом. В эти сети уже попались редкие архивные варианты (:
Alexander
И подход ещё не переносим и не повторяем, приходит следующий за 3000$ и переделывает на фрибсд
Alexander
Так и живем
Roman
это типично отечественный инженерный подход: наймите меня за $2000 в месяц, я вам сэкономлю $30 в месяц
это единственно рабочий. когда у клиента будет тупить дисковый io или ещё какая-то веселая проблема производительности что вы делать будете? :)
Maksim
ты мне сейчас хочешь рассказать слезную историю о том, что наш флюссоник жрет очень много ресурсов и требует дорого железа, а вот какой-то софт, про который тебе рассказывали, запускается на арме от скейлвей и раздает 10G за 5 баксов в месяц
Maksim
не хочу тебя расстраивать, но никаких особых хитростей тут нет. Я тебе ещё раз рекомендую посмотреть на опыт однокласников, которые просто правильным инженерным решением с помощью обычной явы раздают 40G с коробки
Maksim
это очень грубая оценка, которая не отражает реальности
Maksim
нет способа перегнать с диска в tcp сессию на карте в обход памяти и процессора, а значит всё равно будет передача в общую память и раздача оттуда
Maksim
насколько я понимаю, разницы тут между read и всякими спец-штуками не будет, потому что это всё равно все идет к диску сквозь его vfs cache и уже какой-то код внизу просит подогнать данные в память
Maksim
разница только в том: происходит memcpy из памяти ядра в память процесса или нет
Maksim
или я неправ?
« Rev
@devops_ru   180
Fwd »