Разница в производительности между ramfs и tmpfs

23

Мне нужно настроить систему хранения в памяти для примерно 10 ГБ данных, состоящих из множества отдельных файлов (изображений) по 100 КБ. Будет много чтений и довольно периодических записей (добавление новых файлов, удаление некоторых старых).
Теперь я знаю, что tmpfs ведет себя как обычная файловая система, для которой вы можете, например, проверять свободное / используемое пространство с помощью df , что очень удобно. Тем не менее, мне интересно , предложат ли ramfs некоторые преимущества в отношении скорости операций ввода-вывода. Я знаю, что не могу контролировать размер используемой памяти при использовании ramfs и что моя система может зависать, если она полностью использует свободную оперативную память, но это не будет проблемой в этом сценарии.

Подводя итог, я заинтересован:
- Производительность, которая быстрее: ramfs или tmpfs (и, возможно, почему)?
- Когда tmpfs использует пространство подкачки? Перемещает ли уже сохраненные данные в раздел подкачки (чтобы освободить ОЗУ для других работающих в данный момент программ) или только новые данные, если в этот момент не осталось свободной ОЗУ?

linux performance filesystems ramdisk tmpfs Иван Ковачевич
источник
Хм, сколько оперативной памяти находится на сервере?
ewwhite
1
Всего на сервере 16 ГБ ОЗУ. Также стоит отметить, что у меня не SSD-накопитель, а один 7200 об / мин. Вот почему я рассматриваю возможность использования какого-либо типа оперативной памяти.
Иван Ковачевич

Ответы:

21

Моя рекомендация:

Измерять и наблюдать реальную активность в нормальных условиях.

Эти файлы вряд ли когда-либо понадобятся и будут обслуживаться из кэша всегда. Но есть хороший инструмент под названием vmtouch, который может сказать вам, что находится в кеше в данный момент. Вы также можете использовать его для блокировки определенных каталогов или файлов в кеше. Посмотрите, как все выглядит после некоторого регулярного использования. Использование tmpfs и ramfs не обязательно для этой ситуации.

Смотрите: http://hoytech.com/vmtouch/

Я думаю, вы будете удивлены, увидев, что наиболее активные файлы, вероятно, уже будут храниться в кеше.

Что касается tmpfs и ramfs, то заметной разницы в производительности нет. Есть эксплуатационные различия. Реальный пример использования - Oracle, где ramfs использовался, чтобы позволить Oracle управлять данными в оперативной памяти без риска их замены. Данные tmpfs могут быть выгружены под давлением памяти. Существуют также различия в изменении размера и изменении настроек на лету.

ewwhite
источник
1
Потрясающая маленькая утилита! +1
Янне Пиккарайнен
1
@ewwhite Отличный ответ. В одном из наших случаев несколько лет назад мы действительно обнаружили, что в основном используемые файлы уже находятся в кеше. Подсказка: Файловые системы в наши дни намного умнее, чем я думаю.
Джаннисапи
13

Не думай об этом. Поместите достаточно оперативной памяти в вашу систему и позвольте кешу диска ядра позаботиться о вас. Таким образом, вы получаете выгоду от чтения, поступающего непосредственно из памяти, при этом сохраняя возможность сохранять данные на диске.

EEAA
источник
1
Моя система в настоящее время имеет 16 ГБ оперативной памяти. Это простая установка Debian под управлением Nginx для обслуживания этих образов. У меня есть сетевое подключение 1 Гбит, которое будет постоянно загружено на 100%, и эти изображения будут отображаться в произвольном порядке. Как вы думаете, ядро ​​будет загружать все эти 10 гигов изображений в любом случае в кеш в этом сценарии?
Иван Ковачевич
3
Да, если в системе достаточно ОЗУ, а другие приложения на сервере не конкурируют за ресурсы ОЗУ, эти файлы останутся в кеше.
EEAA
2
Я занимался администрированием Unix в течение ~ 15 лет, и я никогда не сталкивался с ситуацией, когда tmpfs / ramfs давали бы какую-то выгоду по сравнению с кешем ядра ядра fs. Это не значит, что не существует ситуаций, в которых они могут быть оправданы, но они довольно редки. Как правило, если вам нужен кэш-память RAM, используется слой кэширования специального назначения (Redis / Memcache / и т. Д.).
EEAA
4
Кэширование диска, безусловно, подойдет для случая, когда нужно прочитать образы, но tmpfs или ramfs могут быть полезны, если вы хотите ускорить много случайных / маленьких записей, но связаны с медленным диском со случайным вводом-выводом. О. Помните, что в случае сбоя или сбоя питания в системе содержимое tmpfs исчезнет, ​​поскольку оно (только) находится в памяти.
Мартейн
1
@ Martijn прав. tmpfs и ramfs действительно полезны. Например, я делаю интенсивное переписывание (фильтр-ветвь) репозитория git. Делать это в памяти - быстрее, чем на моем SSD. Кэширование помогает при чтении, а не при записи, поскольку (обычно) Linux должен соответствовать некоторым гарантиям постоянства операций с диском.
Пол Дрэйпер
7

1) Тест производительности.

Используя эту страницу в качестве ссылки, я провел сравнение операций ввода / вывода между tmpfs и ramfs, и в результате он оказался практически идентичным по производительности:

# !mount
mount | grep -E "tmp|ram"
tmpfs on /dev/shm type tmpfs (rw)
ramfs on /mnt/ram type ramfs (rw,size=1G)

# dd bs=1M count=1024 if=/dev/zero of=/dev/shm/test conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.634054 s, 1.7 GB/s

# dd bs=1M count=1024 if=/dev/zero of=/mnt/ram/test conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.559557 s, 1.9 GB/s

# dd bs=1M count=4096 if=/dev/zero of=/dev/shm/test conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 2.5104 s, 1.7 GB/s

# dd bs=1M count=4096 if=/dev/zero of=/mnt/ram/test conv=fdatasync
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 2.36923 s, 1.8 GB/s

2) Согласно этой странице , tmpfs использует swap, а ramfs не использует swap.

Майкл Мартинес
источник
2
Ваш ответ на правильном пути. Однако я не согласен с вашим выводом относительно производительности, ваши тесты показывают, что существуют различия в 0,2 ГБ / с и 0,1 ГБ / с в пользу ramfs. Я считаю, что это следует проверить еще дальше, чтобы получить достоверную статистическую выборку. Относительно 2) Да, это известно, однако я хотел бы получить лучшее представление о том, когда именно используется своп.
Иван Ковачевич
если мы проводили этот тест несколько раз с файлами разного размера, я не думаю, что мы увидим разницу. вы заметите, что когда я увеличил размер в четыре раза, разница фактически сузилась, а не увеличилась.
Майкл Мартинес
1
Как насчет случая, когда у вас есть куча маленьких файлов. Например, написание миллионов 100-200 кб файлов. Также вы получаете разность 0,2 ГБ / с для одного и того же размера файла? Что определенно указывало бы на разницу в производительности. Я, наверное, сам проверю это, когда оно у меня в расписании. Но вот почему я спросил здесь, так что я мог бы вычеркнуть его из списка дел, если кто-то еще это сделал.
Иван Ковачевич
да, единственный способ узнать наверняка, это сделать тесты.
Майкл Мартинес
1

Если у вас установлено достаточное количество оперативной памяти для размещения различных буферов ядра, стека и кучи приложений, обычного кэша файловой системы и всех файлов, которые вы намереваетесь поместить в него, ramfsникогда не должно быть медленнее, чем, tmpfsпоскольку не будет никакого риска физический ввод / вывод по конструкции. Физические операции ввода-вывода, несомненно, являются основной причиной снижения производительности в этой области.

Однако, если у вас не установлен такой объем ОЗУ, использование ramfsможет и, вероятно, будет медленнее, чем то, tmpfsчто последний использует эвристику виртуальной памяти, чтобы решить, что лучше должно быть на диске (то есть в области подкачки), а что должно быть в ОЗУ. в то время как tmpfsданные вашей файловой системы застряли в оперативной памяти, что может быть пустой тратой ресурсов.

Чтобы ответить на второй вопрос, да, tmpfsсначала будут перемещены старые данные в область подкачки, а не последний «горячий».

jlliagre
источник