«Одно из заметных ускорений Btrfs связано с записью на жесткие диски. Когда несколько задач одновременно сохраняли изменения в журнал, файловая система делала лишнюю паузу — ждала один такт системного таймера. Разработчики убрали это, и сразу в тесте скорость выросла примерно в пять раз.»
Маркетинговый бред и свобоблудие копирайтеров Selectel, банально маскирует/дезавуирует тот факт, что случившийся прирост «до 5 раз» — это лишь в контексте специфических синтетических тестов и лишь в строго определённых сценариях нагрузки.
Суть измененийУпомянутое устранение задержки не затрагивает работы btrfs на SSD и NVMe дисках. Касается только лишь HDD, когда btrfs видит, что работает на HDD и никак не проявляясь для дисков монтируемых как SSD.
Это всё касается лишь весьма специфичных операций записи на диск. Такого типа, когда некая СУБД или другой софт, требует от файловой системы гарантировать, что управление софту не будет возвращено до тех пор, пока вот эти, особо ценные записываемые данные, не окажутся гарантированно записанным на энергонезависимую память.
Откуда взялась проблема — лет пятнадцать назад была идея объединять в пачку сразу несколько операций журналируемых записей (выполняемых через
fsync()). Позиционирование головки операция длительная и ресурсоёмкая, было стремление повлиять на IOPS объединяя небольшие транзакции. Примерно по той же логике, что и очередь операций NCQ в контроллере HDD.
Проблемы масштабируемостиРост количества ядер у процессоров и реально одновременно работающих потоков привёл к снижению производительности из-за давно
известных принципов, которые учитывают в многопоточном (параллельном) программировании, когда хочется наращивать масштабируемость.
На современных CPU, при работе с такими транзакциями записи, большая часть времени стала уходить на выжидание возможности записи в структуры данных промежуточного или точнее легковестного WAL. Выражалось в холостом исполнении программного кода на ядрах процессора в spin-lock'ах, арбитраже шины памяти с неизбежным cacheline bouncing (переписывание в кеше тех строк, которые содержат флагом блокировки). Т.е. чисто аппаратно-хардварные проблемы неоптимального многопоточного кода.
Проявляется лишь при большом количестве потоков, решивших вдруг почему-то начать требовать от файловой системы делать операция гарантирующие сохранение данных в энергонезависимой памяти.
По классике жанра, это всё решается отказом от определённых примитивов блокирующей синхронизации, в пользу lock-free или же wait-free подходов. В данном же случае, изменение в Btrfs гораздо менее значимое. Ни разу ничего кардинально не меняющее, в плане программного кода и механизмов синхронизации, а целиком и полностью сводятся лишь к тюнингу параметров (временной задержке).
Важность и значимостьИзменения почти никого не затронут, кроме отдельных пограничных случаев.
Использование частых операций записи через
fsync() редко использовалось в реальности для компов с HDD-дисками:
- Это приводит к весьма ощутимой фрагментации тех метаданных, которые использует btrfs для организации хранения файлов.
- Сервера давно ушли на SSD и потом на NVMe, смысла в использовании HDD более нет, кроме как в системах хранения данных ориентированных на размещение резервных копий.
- Высокопроизводительные же NVMe-диски давно используют DRAM-кеширование и потому содержат собственные источники питания или обязывают владельца сервера обеспечить работу от UPS в случае отключения электричества.
Другие изменения в 7.3 ядреПомимо расписанного «задержки для non-SSD» есть ещё три значимых изменения в работе Btrfs:
- Гарантированная запись в sparseness-файлы
- Специальный буфер прямого ввода-вывода
- LRU в заблокированных буферах блоками данных
Серьёзные же изменения производительности, по итогу, могут наблюдаться лишь на некоторых вариантах серверного использования. На обычных десктопах и ноутбуках будет как максимум до 20...25 % увеличения производительности дисковых операций «по итогу» (за счёт отдельных ситуаций).
А те, кто привык использовать сервера, уже давно заводят отдельные директорий под СУБД или образы виртуальных машин, для которых отключается CoW до создания там файлов:
chattr +CИли же используя non-CoW разделы на других файловых системах, сродни XFS или Ext4.
Освещение измененийSelectel основательно подгадило в своём корпоративном блоге, явно не считая надобным пристойно донести суть изменений в релизящемся 7.3 ядре.
А дальше, набегают разные хомячки как с идиотами, так и альтернативно одарённыыми, и начинают уже в меру своего понимания, растаскивать по социальным сетям. Активнейшим образом играя по правилам испорченного телефона.
Вот тут ниже есть пример типичного любителя играть в испорченный телефон. Имеющего уровень профессиональной квалификации сильно ниже плинтуса. Зачем ему, расписному, париться нудятиной всякой? Ведь ясно же и так, что из тех которые видят суть вещей или априори знают правду :)
#btrfs #linux #selectel #lang_ru
Одно из заметных ускорений Btrfs связано с записью на жесткие диски.....
Разработчики убрали это, и сразу в тесте скорость выросла примерно в пять раз.
——
Все казалось мне сырым. Может ли в зрелом продукте что-то вырасти в 5 раз ?
