Предварительно загруженный кэш небольших файлов
Во-первых, мой вариант использования: на моем сервере под управлением Linux я получаю неудовлетворительную производительность дискового ввода-вывода для небольших файлов и ограничен примерно 100 IOPS, которые поддерживает жесткий диск со скоростью 7200 об/мин. Это, конечно, ожидаемо, и я ищу способ улучшить производительность. Это особенно проблематично, поскольку я работаю с базами кода, включающими 10000 исходных файлов и объектов. Общий объем данных неэкономичен для SSD. Разделить большие файлы (которые занимают большую часть памяти) и маленькие файлы невозможно.
Типичным решением было бы использование системы кэширования, такой как lvmcache, но, насколько я понял, в стандартной конфигурации она обеспечивает прирост производительности только для часто используемых файлов (поправьте меня, если я ошибаюсь!). Это не соответствует моему варианту использования. Доступ к файлам осуществляется довольно случайно и редко.
Таким образом, возникает вопрос: можно ли настроить кеш для предварительной загрузки небольших файлов и имеет ли это смысл? Они составляют лишь небольшой процент от общего использования хранилища и полностью поместятся на SSD. Я бы хотел, чтобы они жили там постоянно и имели доступ по требованию. Я не вижу никаких технических проблем, но мне не удалось найти подобного документированного поведения, за исключением некоторых суперкомпьютерных систем хранения данных ^^
2 ответа
Определите, какой будет приемлемая производительность. Возможно, загрузка всего проекта небольшого размера займет не более одной-двух секунд. Наличие целей производительности, определенных пользовательским опытом, обеспечивает четко определенные цели.
Проверьте, как хранятся файлы. Десятки тысяч файлов приближаются к худшему варианту с большим количеством операций ввода-вывода для файлов и метаданных. Базы данных или архивы лучше упаковывать в более крупные пакеты с меньшим количеством операций ввода-вывода. Другими словами, системы контроля версий и архивные файлы, особенно при работе с кодом с течением времени.
Поскольку это Linux, разработчики любят изобретать велосипед. Итак, существует множество реализаций блочного кэша, наиболее поддерживаемыми, вероятно, являются lvmcache и bcache. По крайней мере, оба они являются основными ядрами, что приводит к таким сравнительным тестам . Хотя похоже, что RHEL не готов поддерживать bcache.
Невозможно сделать гибридное блочное устройство таким же быстрым и простым в использовании, как флэш-установку. Будут промахи в кэше. Произойдут сбои устройства кэширования, и в этот момент вам лучше узнать, находится ли оно в режиме сквозной или обратной записи, и связано ли восстановление с потерей данных. Это компромиссы в пользу менее дорогого хранилища в целом.
Это блочные устройства, они находятся на уровень ниже файловой системы и не знают о небольших файлах . Однако, в зависимости от того, насколько глубоко вы хотите углубиться в настройку, они могут обнаружить последовательные блочные операции ввода-вывода. Это может быть приемлемым прокси, в зависимости от того, насколько фрагментированы файлы.
Дистрибутив с хорошей документацией по хранению будет охватывать lvmcache. Вот примеры lvmcache из RHEL 9 . Вам нужен кэш типа, просто запись через writecache не будет достаточным стимулом.
Будьте осторожны: в базовых настройках dm-cache упоминается «sequential_threshold», но это не имеет никакого эффекта. В современных ядрах политика замены кэша заменена на более быструю, но без ручек.
Просто блочные кеши не имеют механизма предварительной выборки, особенно для целевого подмножества файлов. Опять же, слой блоков не знает о файлах. Что-то должно будет выполнить ввод-вывод, чтобы они знали, что что-то горячо. Покопавшись в архивах Server Fault, у некоторых есть предварительно разогретые кэши путем чтения файлов.
Обратите внимание, что ОЗУ по-прежнему быстрее твердотельного, а Linux всегда поддерживает файловый кеш. Увеличение объема оперативной памяти приведет к увеличению рабочего набора этого кэша, хотя учтите, что сначала он должен быть медленным, пока коэффициент попадания не улучшится. Однако я рекомендую инвестировать во всю флэш-память, прежде чем тратить лишнюю оперативную память на решение этой проблемы.
Попробуйте закрепить их в vcache с помощьюvmtouch( https://hoytech.com/vmtouch/). При наличии достаточного количества оперативной памяти время доступа к вашим файлам ускорится.
Также подумайте о SSD — цены в последнее время падали.