[paradox_]

в линуксе можно поэкспериментировать с splice

Изменено 15 января, 2014 пользователем paradox_

[^rage^]

Архив — да, запись и чтение с диска. Причём тут решения есть разные, например при рестриминге для мигрантов в штатах часто используется режим таймшифта, когда поток считывается с диска один раз и дальше уже раздается из памяти.

Вы говорите про 5 гбит/с с одного ядра. В каких условиях? Локальная сеть?

нет, стриминг в интернеты.

 

Плюс у меня всё таки есть серьезные вопросы насчёт того, как же sendfile может разблокироваться если нет данных в vfs cache. Вы про какую ОС говорите?

ну так для этого через fincore мы узнаем о наличии региона файла в vfs cache и если нет - просим через posix_fadvise это закешить.

речь про linux.

[maxlapshin]

Про fincore я не знал, штука интересная, да.

 

Я вижу, что связка fincore и posix_fadvise ничем не отличается от read с nonblock, потому что надо поллить что бы сделать чтение.

[^rage^]

вы путаете асинхронный и неблокирующий ввод/вывод.

модель поведения loop, при не блокирующих выводах - называется async io

чего? сходите вот сюда, я про N1&N2, вы же про N3.

 

про sendfile хорошо обьясняли и дискутировали, пришли к заключениям в меил листах nginx, на линуксах он не заработает, только freebsd и только с ее AIO

т.е. "не работает"?

[SmokerMan]

И все же, к кого-нибудь астра вещает в http так, чтобы в vlc показывало нормально?

[^rage^]

Про fincore я не знал, штука интересная, да.

 

Я вижу, что связка fincore и posix_fadvise ничем не отличается от read с nonblock, потому что надо поллить что бы сделать чтение.

да, ядро не предоставляет нотификаций, что данные осели в кеше.

а чем read с O_NONBLOCK поможет на обычных файлах? и вообще какой смысл в O_NONBLOCK на файлах, если только речь не aio_read?

 

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

если рассматривать пока исключительно live, то задача вполне реализуемая. в конце-концов, в linux есть splice: можно хоть целиком сегмент загнать в kernel buffer.

[maxlapshin]

Вы поймите, я исхожу из того, что сервер запускается в плохо контролируемых условиях.

 

Например вы пишите на диск, в надежде что все данные будут в vfs кеше, а потом на этом же сервере кто-то запускает чудо-скрипт, который начинает лопатить жесткий диск или писать логи на него так активно, что вытесняет данные из vfs кеша. После этого решение с чтением с диска может залипнуть на одном единственном файлике.

 

Вы скажете, что у вас такого не будет? Это пока вы один контролируете сервер. Мне приходится работать в ситуации, когда я вообще не имею доступ к серверу пользователя и выбираю решения, которые работают даже когда на сервер ставят десктопную убунту и загружают этот сервер ещё каким-то говнищем настолько, что даже access log приходится выключать.

[paradox_]

чего? сходите вот сюда, я про N1&N2, вы же про N3.

с чего вы взяли что я про N3?

я тоже про 1&2 но словами это так же сказано и в 3

This has not yet become popular in Unix, probably because few operating systems support asynchronous I/O, also possibly because it (like nonblocking I/O) requires rethinking your application.

про aio_* я вообще не говорил и не думал

 

т.е. "не работает"?

конечно нет, блокируется на чтении пока не скинет весь файл

[^rage^]

Вы поймите, я исхожу из того, что сервер запускается в плохо контролируемых условиях.

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

 

Например вы пишите на диск, в надежде что все данные будут в vfs кеше, а потом на этом же сервере кто-то запускает чудо-скрипт, который начинает лопатить жесткий диск или писать логи на него так активно, что вытесняет данные из vfs кеша. После этого решение с чтением с диска может залипнуть на одном единственном файлике.

вопрос вымывания данных из кеша тоже решаемый. кстати, с записью ведь тоже всё сильно зависит от сценария. например, у нас только что записанные данные в 98% случаев сразу ненужны и как только сегмент лег на диск - через POSIX_FADV_DONTNEED выкидывается из кеша.

 

Вы скажете, что у вас такого не будет? Это пока вы один контролируете сервер. Мне приходится работать в ситуации, когда я вообще не имею доступ к серверу пользователя и выбираю решения, которые работают даже когда на сервер ставят десктопную убунту и загружают этот сервер ещё каким-то говнищем настолько, что даже access log приходится выключать.

кстати, мы как раз используем ubuntu. а про решения - да, компромиссы. тут всё очень похоже на ситуацию с posix: либо быстро и на каждой платформе своё, либо медленно.

[^rage^]

чего? сходите вот сюда, я про N1&N2, вы же про N3.

с чего вы взяли что я про N3?

я тоже про 1&2 но словами это так же сказано и в 3

This has not yet become popular in Unix, probably because few operating systems support asynchronous I/O, also possibly because it (like nonblocking I/O) requires rethinking your application.

про aio_* я вообще не говорил и не думал

вы заговорили про freebsd aio.

 

про sendfile хорошо обьясняли и дискутировали, пришли к заключениям в меил листах nginx, на линуксах он не заработает, только freebsd и только с ее AIO

 

Вообще, у вас каша в голове, хотя бы потому что официальная документация на nginx явно говорит от выключении sendfile для использования AIO

Для работы AIO нужно выключить sendfile

 

 

т.е. "не работает"?

конечно нет, блокируется на чтении пока не скинет весь файл

конечно нет что? я же говорю, у вас в голове путаница между nonblocking i/o и aio.

[paradox_]

^rage^

у меня все хорошо

это у вас путаница между общим aio_* и общей концепцией логики построения приложений на async io(select poll итд) которая цепляет nonblocking i/o

Изменено 15 января, 2014 пользователем paradox_

[Ivan_83]

Вообще, у вас каша в голове, хотя бы потому что официальная документация на nginx явно говорит от выключении sendfile для использования AIO

Чуть ниже прочитай, там вариант с подгрузкой данных через аио и отправкой сендфайле.

[^rage^]

Вообще, у вас каша в голове, хотя бы потому что официальная документация на nginx явно говорит от выключении sendfile для использования AIO

Чуть ниже прочитай, там вариант с подгрузкой данных через аио и отправкой сендфайле.

ну так там жуткий костылизм. фактически, fincore+fadvise делают то же самое. только окно для readahead больше и ты его контролируешь.

[^rage^]

^rage^

у меня все хорошо

это у вас путаница между общим aio_* и общей концепцией логики построения приложений на async io(select poll итд) которая цепляет nonblocking i/o

select/poll не работают на обычных файлах и всегда возвращают готовность к чтению или записи.

[maxlapshin]

Правильно. Потому что poll для сокета означает, что данные появились в трубе, а что может означать poll для файла, если файл предоставляет возможность добраться до любого куска данных?

[paradox_]

всегда пишу быстро и тезисно не рассписывая, видимо из за этого путаница в понимании меня

 

- я не говорил о select/poll на файловое чтение

* нюансы о том что вернет read когда файл еще в процессе записи а хочется уже читать

* в бсд kqueue мощнее

- sendfile в фрибсд не блокируется

- aio_* в линуксе появилось по моим меркам недавно, но помоему слабоватый

- со splice не сталкивался, но интересно применение вместо sendfile на линуксе

если опять меня не поняли, бросаем этот разбор))

[Ivan_83]

ну так там жуткий костылизм. фактически, fincore+fadvise делают то же самое. только окно для readahead больше и ты его контролируешь.

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

Вероятно для разработчиков удобно что aio работает с kqueue.

 

а что может означать poll для файла, если файл предоставляет возможность добраться до любого куска данных?

Тоже самое что для сокета с данными: готовность на чтение в юзерский буфер.

[maxlapshin]

Тоже самое что для сокета с данными: готовность на чтение в юзерский буфер.

 

Нее =)

 

Когда мы делаем read(fd) из сокета, то считываем байты из очереди, поэтому готовность сокета это просто наличие байт в очереди.

 

Когда мы делаем read(fd) из файла, то готовность на чтение уже не так просто вычисляется. Надо отправить системе запрос на чтение: fd, start, count и попросить ОС известить, когда указанный range окажется в vfs кеше. И не дергать её постоянно.

[^rage^]

- я не говорил о select/poll на файловое чтение

* нюансы о том что вернет read когда файл еще в процессе записи а хочется уже читать

* в бсд kqueue мощнее

1. т.е. "в процессе записи"? запись и чтение никак не связаны(ну, кроме логики приложения).

2. да, есть приятные плюшки.

 

- sendfile в фрибсд не блокируется

ну да, с SF_NODISKIO. но то что делается дальше мне совсем не нравится: "В такой конфигурации функция sendfile() вызывается с флагом SF_NODISKIO, в результате чего она не блокируется на диске, а сообщает об отсутствии данных в памяти. После этого nginx инициирует асинхронную подгрузку данных, читая один байт. При этом ядро FreeBSD подгружает в память первые 128K байт файла, однако при последующих чтениях файл подгружается частями только по 16K."

 

при этом мы надеемся на механизмы readahead в ОС и слабо можем происходящее контролировать. И чем это лучше fincore+fadvise, когда мы явно можем знать наличие региона в кеше?

 

- aio_* в линуксе появилось по моим меркам недавно, но помоему слабоватый

aio возможен только с O_DIRECT, что поставит диски в весьма интересную позу. если нас не интересует содержимое файла и его просто надо отдать в сеть - aio не нужен(а нужно что-то вроде виндового IOCP).

 

- со splice не сталкивался, но интересно применение вместо sendfile на линуксе

я использовал splice. много и в разных вариантах: 1) сеть => сеть, 2) сеть => диск 3) диск => сеть.

более того, где-то с 2.6.21 sendfile реализован через splice со всеми вытекающими(например, нет требования чтобы выходной fd являлся сокетом. так что современным sendfile в linux можно копировать файлы).

сам sendfile покрывает лишь 3й сценарий использования.

со splice у нас в 2 раза больше сисколлов для одной и той же операции( in_fd => pipe => out_fd ), но никаких ограничений на типы файловых дескрипторов.

Например, для задачи записи видео на диск, чтобы не блокироваться в основном процессе, я сначала сплайсил данные в pipe(ничто не мешает иметь пайпы размером хоть 1Гб), а потом через sendmsg отсылал этот пайп в дочерний процесс, которому блокироваться было не страшно(и который сначала звал fallocate).

 

для стриминга я пробовал вариант splice+tee ( делаем splice в pipe, потом этот pipe "клонируем" с помощью tee - по факту просто игры с указателями внутри ядра ), но потом нашел простое решение с sendfile.

[maxlapshin]

Например, для задачи записи видео на диск, чтобы не блокироваться в основном процессе, я сначала сплайсил данные в pipe(ничто не мешает иметь пайпы размером хоть 1Гб), а потом через sendmsg отсылал этот пайп в дочерний процесс, которому блокироваться было не страшно(и который сначала звал fallocate).

 

Зачем такие хитрости, когда можно просто в отдельном треде записать?

[^rage^]

Например, для задачи записи видео на диск, чтобы не блокироваться в основном процессе, я сначала сплайсил данные в pipe(ничто не мешает иметь пайпы размером хоть 1Гб), а потом через sendmsg отсылал этот пайп в дочерний процесс, которому блокироваться было не страшно(и который сначала звал fallocate).

 

Зачем такие хитрости, когда можно просто в отдельном треде записать?

с процессами проще, а треды хрупкие.

[Silius]

А тема то началась с простого вопроса про Vlc и Астру, а переросла в программерское обсуждение проблемы :)

[uk2558]

И все же, к кого-нибудь астра вещает в http так, чтобы в vlc показывало нормально?

У меня - и на трех разных вендорах STB, на VLC, на IP-TV PLayer, даже на android девайсах показывает нормально.