дисковый асинхронный ввод-вывод

posix aio реально используется в 2017 году?

А какие существуют кроссплатформенные альтернативы? Пазикс наше всё.

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

Глянь реализацию sendfile в FreeBSD. Там как раз асинхронный вывод из файла в сокет, может чего полезного накопаешь.

libuv на Linux для дискового IO использует thread-pool. Сетевые сокеты мониторятся epoll. В нем же мониторятся и сигналы от пула тредов (которые отправляются когда операция завершается)

обдумываю сейчас реализацию eventloop-а и для сетевых сокетов и для дискового I/O...

А что мешает заюзать готовые реализации?

Да, есть реализация AIO на уровне ядра Linux, в которой не требуется треды создавать, но оно не портабельно

см. https://cebka.blogspot.com/2012/05/aio-linux.html

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

Никакого асинхронного дискового IO не существует нигде. Есть какие-то попытки сделать асинхронное чтение/запись, но это лишь часть большой задачи, потому что есть ещё open, stat, а по моему опыту забитый шпиндель может отдать ответ на stat где-нибудь через 30-40 секунд. Весь твой event loop летит к черту.

Короче, thread pool, потом потыкайся в libuv когда наиграешься, а затем бери эрланг и расслабься. Там всё есть и сделано гораздо лучше.

Весь твой event loop летит к черту.

потом потыкайся в libuv когда наиграешься

вот libuv и вдохновил свой цикл сделать чтоб разобраться с нуля... в libuv для сетевого ввода/вывода используется epoll, а для дискового posix aio + thread pool? если так, то почему все говорят что node.js все делает в один поток?

эту ссылку видел... т.е. нужно самому обертки писать до сих пор? просто думал может уже реализовали все и устаканили

потому что тредпул только для дисков. Всё остальное нода обречена делать в один поток

а сколько потоков в тредпуле там?

это очень сложный вопрос, потому что по идее надо иметь порядка 20-80 (it depends) на один девайс. Но рейд всё поменяет

libuv на Linux для дискового IO использует thread-pool. Сетевые сокеты мониторятся epoll. В нем же мониторятся и сигналы от пула тредов

нет сейчас возможности смотреть код libuv... я так понимаю пул тредов «пишет» в какой-то unix-сокет который тоже опрашивается в epoll? или как тогда

Нафиг тебе epoll? Чем обычный select не устраивает?

эффективней же

по идее надо иметь порядка 20-80 (it depends) на один девайс

пытаюсь понять: а зачем так много? вот вызвали read - один поток для этого read... вызвали write - 1 поток для write и т.д.

С какого перепугу? select — простая штука, а с epoll ты будешь вынужден сношаться...

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

спасибо, надо будет просветиться

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

Я знаю пример с прошлой работы, когда эта замечательная идея выродилась в 18 тысяч тредов в одном-единственном процессе.

зачем так много?

В Linux нет асинхронного ввода/вывода для дисковой подсистемы, только для прямого (некешируемого) ввода/вывода (DIRECT IO). posix эмулирует его с помощью потоков. Если такая задача возникнет, то лучше всего это реализовать самому на пуле потоков (как это сделали nginx).

Глянь реализацию sendfile в FreeBSD.

Во FreeBSD асинхронные дисковые операции реализовали Netflix специально для себя (очень недавно). В Linux такого нет.

Ну я и написал же — посмотри как реализовано, может что-то полезное увидишь. Можно ещё в стрекозе покопаться на предмет идей полезных :)

Если такая задача возникнет, то лучше всего это реализовать самому на пуле потоков

в смысле реализовать на posix aio + пул потоков?

в смысле реализовать на posix aio + пул потоков?

Вообще без posix AIO. Очередь, в которую ставятся заявки на чтение/запись + пул потоков, который исполняет запросы и уведомляет заказчика. Более того, если это не библиотека для неопределенного круга пользователей, а решение для конкретной задачи, то с учетом того, что запись всегда делается в кеш ОС, ее имеет смысл делать асинхронной только для случая, когда есть шанс, что оперативки будет не хватать для кеширования. Однако, в этом случае все приложение целиком начнет тормозить, вместе с операционкой из-за нехватки памяти и забитого на 100% ввода/вывода (у компа есть три основных ресурса - CPU, размер RAM и производительность IO из них 2 будут забиты на 100%).

Вообще без posix AIO

а чем это лучше чем posix AIO? тоже самое ж имхо

зачем так много?

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

В Linux нет асинхронного ввода/вывода для дисковой подсистемы, только для прямого (некешируемого) ввода/вывода (DIRECT IO).

Подсистема, которая в каталоге block в исходниках ядра, та вся асинхронная. В файловой семантике POSIX асинхронности нет, да.

а кстати как параллельно на диске может осуществляться ввод/вывод если читающая головка одна?

читающая головка одна

Нет. И вообще, чтение не так примитивно.

Начали 25 лет назад, когда нагрузка сильно меньше была и треды дешевле

Это в каком плане треды были дешевле 25 лет назад?

Это в каком плане треды были дешевле 25 лет назад?

Ну потери на свитч стали дороже и в софте, и в самом железе. А тогда там вообще юниксоподобное ядро без юзерспейса было.

Это в каком плане треды были дешевле 25 лет назад?

Ну потери на свитч стали дороже и в софте, и в самом железе

В абсолютном времени они стали меньше и в железе, и в софте (по крайней мере, в ОС).

А тогда там вообще юниксоподобное ядро без юзерспейса было.

Хотя, если раньше всё было в едином адресном пространстве ядра, а потом перешло в Unix-процесс, тогда расходы могли и возрасти.

В абсолютном времени они стали меньше и в железе, и в софте (по крайней мере, в ОС).

В тактах больше.

Почему это важно?

Почему это важно?

Кусок кода от переключения до переключения стал выполняться быстрее, а само переключение только прямо измеряемого времени - почти в 10 раз больше (по сравнению с юниксоподобным ядром). И, глядя на perf, прямо неизмеряемых потерь ещё прилично есть: кэш, TLB, ступор pipeline.