У нас есть сервер с 64 ГБ общей оперативной памяти, приложения обычно используют максимум 30 ГБ этой доступной оперативной памяти. Одно из этих приложений работает с большим количеством плоских файлов, и у нас возникают проблемы с пропускной способностью, а именно ожидание ввода-вывода на диске. При изучении возможных решений возникла идея RAM-диска. Проблема, с которой я сталкиваюсь с RAM-диском, заключается в его внутренней нестабильности.
Я нашел отдельную документацию по RAM-дискам, конфигурации RAID 1 и логическим зеркальным томам для группировкифизическийdisks, но я не могу найти никакой документации, которая бы указывала, можно ли использовать любое из этих решений репликации дисков с RAM-диском. Что еще важнее, поскольку идея заключается в том, чтобы RAM-диск был доступен для чтения/записи, а физический диск «затенял» RAM-диск, догоняя записи, мы хотели бы, чтобы RAM-диск был «основным» диском для всех чтений/записей.
Отметим, что мы хотели бынравитьсячтобы избежать простого кэширования файлов в RAM с ОС, но если мы сможем получить ту же производительность, что и автономный RAM-диск, это может сработать. Мы изначально избегали этого, поскольку часто некоторые файлы не будут доступны в течение длительных периодов времени, но все еще нуждаются в скорости чтения/записи по требованию.
решение1
Заметим, что мы хотели бы избежать простого кэширования файлов в RAM с ОС, но если мы сможем получить ту же производительность, что и автономный RAM-диск, это может сработать. Изначально мы избегали этого, поскольку часто некоторые файлы не будут доступны в течение длительных периодов времени, но все равно нуждаются в скорости чтения/записи по требованию.
Вы могли бы использоватьvmtouchдля решения вашей проблемы.Это утилита, которая позволяет вам закреплять определенные файлы или даже целые каталоги и все, что находится под ними, в кэше страниц, чтобы они не были вытеснены, даже если к ним не обращаются в течение длительного времени (что было вашей первоначальной причиной не полагаться просто на кэш страниц). Для этого требуется максимум тот же объем памяти, что и на вашем RAM-диске, или на практике меньше. Вы по-прежнему будете использовать кэш страниц, но это приведет к производительности, аналогичной использованию RAM-диска для всего (на самом деле, более высокой производительности, поскольку драйвер MD не будет задействован).
решение2
Это можно было бы сделать самостоятельно, но это плохая идея, и, скорее всего, у нее есть множество проблем с надежностью и удобством обслуживания.
Я думаю, что RAID1 из RAM-диска и физического диска будет ограничен производительностью физического диска, поскольку часть функциональности RAID1 заключается в обеспечении синхронизации обеих копий.
Для чтения может быть некоторая выгода, поскольку драйвер MD может распределять чтение между различными устройствами.
Возможные шаги для создания этого:
- Создайте пустой файл, имеющий размер массива, который вы хотите поддерживать.
- Используйте
losetupдля создания блочного устройства из файла. - Используется
mdadmдля создания массива с вновь созданным блочным устройством и соответствующим разделом жесткого диска. - Создайте файловую систему на новом массиве MD.
Я сам этого не пробовал, так что это всего лишь теоретический пример того, как это можно сделать.
решение3
Во-первых, RAM-диск — это почтиникогдаправильный ответ на Linux. Поскольку это блочное устройство, в конечном итоге любое чтение должно проходить через блочный уровень, файловую систему и обычный уровень VFS,иданные в конечном итоге будут кэшироваться в RAM в дополнение к хранению на RAM-диске. Это дублирование данных, а также количество дополнительных задействованных слоев — вот почему tmpfs существует в Linux; вместо использования блочного слоя файловая система tmpfs просто хранит данные непосредственно в кэше страниц, пропуская всю дополнительную сложность. Она также автоматически выбирает размер на основе объема хранящихся в ней данных (вместо того, чтобы заранее определять размер), и она даже может использовать пространство подкачки. Если вы считаете, что вам нужен ramdisk, то в 99% случаев вам действительно следует использовать tmpfs.
Теперь, что касается реальных решений...
Если все ваши данные действительно помещаются в ОЗУ, вам гораздо лучше просто закрепить их все в ОЗУ, используя такой инструмент, какvmtouchили заставив приложение mmap отобразить все файлы, а затем вызвать mlock для всех отображенных регионов.
Если все ваши данные не помещаются в оперативную память, у вас есть два реалистичных варианта:
- Сохраните сжатые данные на диске, в идеале используя файловую систему, которая обеспечивает прозрачное сжатие, например BTRFS, F2FS или ZFS. При условии, что у вас достаточно быстрый процессор, это обычноуменьшатьвремя, необходимое для чтения большого файла, за счет немного большего потребления процессорного времени. Улучшение обычно пропорционально тому, насколько хорошо сжимаются данные, но во многих случаях может легко перерасти в улучшение на 30% и более.
- Рассмотрите возможность инвестирования в более быстрое хранилище. Либо достаточно, чтобы просто заменить существующее хранилище, либо немного меньшего объема, который вы затем сможете использовать сbcacheдля функционального ускорения вашего существующего хранилища.
решение4
Если вам нужна сохранность, RAMDISK — неподходящее решение.
Я настоятельно рекомендую инвестировать в пару быстрых (читай: корпоративного уровня, с защитой от сбоев питания) дисков NVMe для создания классического массива RAID1 (зеркального).