Вопрос или проблема
Я только что услышал об eatmydata, который отключает fsync для ускорения работы, когда безопасность данных не требуется (тесты, сборки CI и т. д.):
libeatmydata — это небольшая библиотека LD_PRELOAD, предназначенная для (прозрачного) отключения fsync (и его друзей, таких как open(O_SYNC)). Это имеет два побочных эффекта: делает так, чтобы программное обеспечение, записывающее данные безопасным образом на диск, работало намного быстрее, и делает так, чтобы это программное обеспечение больше не было устойчивым к сбоям.
Он появился в 2007 году, но все еще активно поддерживается на Github. Однако не все дистрибутивы включают его; например, в Fedora есть пакет nosync, который более или менее эквивалентен (он не включает команду-обертку, но вместо этого требует использования LD_PRELOAD).
Однако, после того как я попробовал его на нескольких рабочих нагрузках на разных машинах (одна с HDD, другая с SSD) как на Ubuntu, так и на Fedora, различия во времени выполнения были незначительными: около 5 секунд на задаче длительностью 2 часа; 0,5с на задаче длительностью 2 минуты и т.д. Согласно результатам Google, пользователи прошлого сообщали о весьма значительных улучшениях во времени выполнения.
Произошло ли что-то с тех пор, что сделало эту “оптимизацию” ненужной? Являются ли последние версии ОС более умными в обращении с fsync? Существует ли какая-то работа, которую легко протестировать, в которой все еще можно наблюдать большие различия?
когда безопасность данных не нужна (тесты, сборки CI и т. д.):
Тесты и сборки CI в общем-то не используют явный fsync много. Насколько я видел, наиболее распространенные случаи использования eatmydata были в ситуациях, когда каждый. отдельный. файл. должен был фсинкаться перед переходом к следующему. Два примера этого — фаза распаковки apt-get и различные операции в SVN (такие как svnsync sync).
Являются ли последние ОС более умными в обращении с fsync?
Файловые системы могут обрабатывать это по-разному, например, если я правильно помню, ext4 работал таким образом, что fsync’и отдельных файлов были гораздо более глобальными, чем обычно (и недавно добавленная функция “fast commit” должна улучшить это), в то время как на том же XFS это может быть не так.
Обратите внимание на то, что “глобальный” означает, что другие задачи, выполняющиеся на той же машине, также имели бы эффект – например, файлы журналов, которые записываются, или просто любая недавняя задача, которая произвела много записей и они всё ещё буферизуются, и попытка fsync() одного файла в итоге вымывает те гигабайты несвязанных записей также. Это то, что вы не увидите, когда используете полностью выделенную, простую систему для ваших бенчмарков…
.
Ответ или решение
Вопрос о релевантности инструмента eatmydata, который отключает fsync для улучшения производительности в ситуациях, когда надежность данных не является критической, весьма интересен и актуален для айти-специалистов. В основе этого вопроса лежит понимание работы систем ввода-вывода и файловых систем в современных операционных средах.
Теория:
Библиотека libeatmydata, разработанная в 2007 году, использует механизм LD_PRELOAD для прозрачного отключения вызовов fsync и аналогичных, таких как open(O_SYNC). Вызов fsync играет важную роль в обеспечении надежности данных, так как он гарантирует, что данные, записанные в файл, действительно будут переданы на физический носитель. Однако использование fsync приводит к значительным задержкам, особенно на HDD, где операции записи более медленные по сравнению с SSD. В ситуациях тестирования или сборки непрерывной интеграции (CI), где потеря данных не критична, повышение скорости может быть полезным. Инструменты, такие как eatmydata, позволяют ускорить процессы, жертвуя целостностью данных.
Пример:
В прошлом, особенно в сценариях, где каждое отдельное файловое действие сопровождалось вызовом fsync (например, распаковка пакетов через apt-get или операции с SVN), использование eatmydata могло давать значительное ускорение. Однако это было особенно заметно на системах с жесткими дисками (HDD), где время доступа к диску было значительно выше по сравнению с современными твердотельными накопителями (SSD).
Применение:
С тех пор произошли значительные изменения в аппаратной части и программном обеспечении. Внедрение SSD, которые имеют значительно меньшее время доступа, все чаще снижает заметность задержек, связанных с вызовом fsync. Более современные файловые системы, такие как ext4, XFS и Btrfs, также внедрили механизмы, уменьшающие задержки при использовании fsync. Например, функция "быстрая фиксация" (fast commit) в ext4 может минимизировать количество операций ввода-вывода, необходимых для выполнения fsync, за счет оптимизации записи журнала.
При тестировании eatmydata на современных системах с SSD и различных операционных системах, пользователи замечают минимальные улучшения производительности: разница во времени выполнения может составлять всего несколько секунд на многоминутных или даже часовых задачах. Это явление можно объяснить тем, что современные аппаратные и программные компоненты лучше оптимизированы для работы с интенсивными операциями ввода-вывода.
Стоит также учитывать контекст, в котором используется eatmydata. В современных CI/CD системах, особенно тех, которые не выполняют интенсивных операций записи, температура вызовов fsync уже минимизирована за счет опросного кэша и другой оптимизации. Например, не всякая тестовая или сборочная среда интенсивно использует fsync, поэтому использование eatmydata станет менее заметным. Однако в специфических сценариях, таких как системные миграции или обновления, где каждый файл fsync-ится индивидуально, eatmydata все еще может быть полезным.
Также важно помнить, что в производственных окружениях отключение fsync может привести к потере данных в случае отказа системы. Однако в безопасных для тестирования средах, где скорость важнее, профессональные команды по-прежнему могут применять такие инструменты, чтобы ускорить процесс разработки и тестирования.
В заключении, хотя инструмент eatmydata и его аналоги, такие как nosync в Fedora, могут играть менее заметную роль на современных системах, они сохраняют свою актуальность в специфических сценариях. Они позволяют айти-специалистам балансировать между производительностью и надежностью данных в зависимости от предъявляемых задач.