Практический подход к неблокирующему вводу-выводу файла
Скорость выполнения и оптимальное использование вычислительных ресурсов - основные цели компьютерных алгоритмов, фреймворков и программ. Скорость доступа к данным - один из основных факторов, определяющих эффективность приложений с точки зрения времени отклика, а также масштабируемости.
Время доступа к памяти зависит от типа памяти, оно увеличивается в следующем порядке: L1, L2, L3 cache, Primary memory,
Вторичная память (доступ к диску, включая SSD-диски). Доступ к диску на несколько порядков медленнее, чем миллисекунды доступа к памяти для HDD и микросекунды для SSD по сравнению с наносекундами для памяти (в современных процессорах).
Буферизация реализована как стандартными библиотеками (libc), так и ОС (буферизованный ввод-вывод), с целью повышения скорости доступа программ к данным. Основным допущением в этой схеме является принцип Временная локальность ссылки (данные, к которым был получен один раз доступ, с большой вероятностью будут снова доступны в ближайшем будущем).
Важно отметить, что принцип временной локальности ссылки не может быть полезным при всех обстоятельствах.
Например, серверные программы обрабатывают входящий файл данных через * HTTP, FTP * или генерируют вывод в файлы в случае отчетов, журналов, файлов для отправки в другие системы. Во всех этих случаях данные после чтения и обработки или данные, записанные на диск, больше не будут использоваться. Хранение страниц из этих файлов в кеше будет пустой тратой памяти.
Еще одно соображение по этому поводу - проблема масштабируемости и потоковой модели. Стратегия DMA позволяет потоку, которому необходимо выполнить ввод-вывод, быть заблокированным, а другой поток будет запланирован для обработки ЦП до тех пор, пока ввод-вывод, запрошенный исходным потоком, не будет завершен. В случае многопоточных серверных программ, когда один поток блокирует некоторый ввод-вывод (файл / сокет), другие потоки обрабатывают новые запросы. Заблокированные продолжают свою обработку после завершения ввода-вывода. В таком сценарии это
становится сложно оценить количество потоков, которые необходимо запустить.
Решение вышеуказанной проблемы предпринимается с помощью фреймворков, реализующих асинхронный ввод-вывод, таких как AIO, IOCP. Они выгружают задачу ввода-вывода в пул фоновых потоков, освобождая тем самым рабочие потоки (которые отправляют запросы ввода-вывода) для обработки других задач (например, более новых запросов), пока ввод-вывод завершается. После завершения ввода-вывода приостановленная задача продолжается.
Одним из ограничений этих фреймворков является то, что операции чтения и записи файлов выгружаются в фоновый режим.
потоки. Существует значительная разница между операциями чтения и записи.
В случае операции чтения: источником данных является диск, а потребителем - рабочий поток. Это случай очень медленного производителя и быстрого потребителя. После того, как запрос отправлен производителю данных, потребитель (поток) может выполнять другие задачи во время выборки данных.
В случае операции записи: источник данных (производитель) - быстрый, а место назначения (потребитель или диск) - медленный. Таким образом, переключение контекста для достижения асинхронного ввода-вывода будет более затратным по сравнению с буферизацией данных в памяти и наличием фонового потока для синхронизации буферизованных данных с диском в медленном механизме синхронизации. Эта стратегия даст лучшие результаты для рабочих потоков с точки зрения времени отклика.
Необходима библиотека обработки файлов, которая решает обе проблемы, упомянутые выше,
- Избегание буфера ОС для файлов, к которым больше нет доступа и
- 2. Реализуйте желаемую стратегию асинхронного ввода-вывода для чтения и записи.
Tekenlight пытается использовать этот подход с помощью библиотеки ввода-вывода файлов под названием efio, которая все еще проходит различные стадии разработки, проверки и тестирования. Планируется, что библиотека будет доступна в рамках либеральной политики лицензирования с открытым исходным кодом.
PS:
Отзывы / комментарии / предложения, а также комментарии по этому поводу приветствуются.
Опубликовано 02 / Мар / 2019
Судхир Х. Р. ([email protected])
