Используя tmpfs + очень большой раздел подкачки для / tmp вместо обычной файловой системы?

8

У меня есть сервер Linux, и у меня есть запасной раздел на 500 ГБ. Я хотел отформатировать его и использовать для / tmp. Сервер иногда выполняет некоторые большие задачи обработки данных, поэтому может случиться, что / tmp будет содержать ГБ временных данных.

Тогда у меня появилась идея, что вместо этого я могу добавить его как раздел подкачки и смонтировать / tmp в tmpfs. Эта идея разумна?

Сервер имеет 6 ГБ ОЗУ, поэтому в большинстве случаев данные на / tmp будут только в ОЗУ с очевидным преимуществом в скорости. Вопрос в том, что если, скажем, на / tmp будет 10-20 ГБ данных, как будет работать система? Какова будет производительность по сравнению с простым подключением / tmp к разделу ext4? Спасибо за помощь.

Редактировать: Понятно, что система начнет выгружать память, когда использование tmpfs достигнет предела оперативной памяти. Но достаточно ли Linux умен, чтобы обмениваться данными tmpfs и хранить «обычные» данные в оперативной памяти? Если да, то я полагаю, что он может вести себя разумно. Если нет, то вся система будет серьезно затронута.

Петр Пудлак
источник
Не забывайте о Zram.
Кен Шарп

Ответы:

12

Это НЕ хорошая идея ТМ .

Вы будете в порядке с большим /tmpразделом, смонтированным так (от вашего /etc/fstab)

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

И вы можете добавить свой внешний диск в качестве гигантского раздела подкачки

/dev/sdb1  swap  swap  defaults  0 0

Когда это достигнет своего предела, ваша машина начнет обменивать страницы из оперативной памяти на диск - в этот момент средние значения нагрузки пройдут через крышу, и машина остановится.

Это плохая идея полагаться на SWAP в любом случае, вам лучше продать свой 500 ГБ диск и просто купить больше оперативной памяти - это дешево.

В итоге

Если вы действительно хотите использовать свой диск объемом 500 ГБ, вы можете смонтировать его на 500 ГБ /tmpс файловой системой без журналирования с отключенным временем и временем (например, ext2). Это было бы значительно быстрее , чем иметь дело с машиной, которая SWAPИНГ

Fran
источник
1
Это ужасная идея. Использование tmpfs и полагаться на него, чтобы подтолкнуть его к обмену, звучит как идея ... но реальность такова, что ваша система может подтолкнуть не те вещи, которые нужно поменять в пользу сохранения tmpfs в физической памяти. Лучше просто смонтировать раздел 500 ГБ в / tmp и покончить с этим. Я бы предложил использовать чрезвычайно легкую файловую систему, такую ​​как xfs riserfs ... так как вы можете быстро переформатировать ее при запуске или всякий раз, когда возникнет такая необходимость ... и вам действительно не нужны все расширенные функции ext2 / 3/4 и тому подобное.
TheCompWiz
3
Почему отрицательный голос? Я не потворствовал этому действию - но предоставлял средства, как это сделать. Вопрос заключался в том, возможно ли это и как с этим справиться - не было ли это хорошей идеей или нет. Я недвусмысленно заявил, что это плохая идея - и что реальным решением должно быть просто купить больше оперативной памяти, если ему нужен более быстрый tmpдоступ.
Фран
1
Это место для хороших идей ... а не решений для клейкой ленты и жевательной резинки. Люди приходят сюда за помощью ... а не за идеями о том, как сделать свою жизнь адом.
TheCompWiz
Я отредактировал свой ответ в соответствии с вашим комментарием, спасибо за ваш вклад
Фрэн
3
Кажется, все здесь согласны с тем, что это плохая идея. Тем не менее, tmpfs.txt в документации ядра перечисляет это как один из вариантов использования tmpfs. @Фран, у тебя есть данные, подтверждающие твое страшное утверждение, что это может привести к избиению? Очевидно, это зависит от того, что пойдет на / tmp.
Migle
1

Это может быть разумной идеей.

Размещение фактической файловой системы в / tmp сопряжено с накладными расходами, поскольку файловые системы проходят большую работу, чтобы убедиться, что данные на диске не повреждены в случае сбоя системы. Для / tmp, который очищается во время загрузки, это явно накладные расходы. Использование tmpfs позволит избежать этих накладных расходов.

С другой стороны, файловые системы также следят за тем, чтобы файлы были организованы на диске таким образом, чтобы оптимизировать время доступа, т. Е. Избежать фрагментации. Типичные последовательные обращения к файлам (в основном) приводят к последовательным обращениям к диску, которые более эффективны, чем произвольные обращения. Этот эффект более выражен на вращающихся жестких дисках, чем на SSD. Комбинация swap + tmpfs не может легко сделать это, потому что swap не знает, какой кусок памяти принадлежит какому файлу, а tmpfs не знает, как страницы отображаются в физическую память или на диск. Однако для больших файлов это должно работать хорошо, так как и tmpfs, и swap стараются поддерживать непрерывность данных в этом случае. По крайней мере, до тех пор, пока на свопе много свободного места (в противном случае начинается фрагментация), и записи происходят достаточно медленно, чтобы у них был шанс на обмен.

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

Когда вы монтируете tmpfs, не забудьте явно указать размер. По умолчанию используется половина физической памяти, поэтому всего 3 ГБ.

Arnout
источник
- разумный ответ (который по иронии судьбы гораздо глубже, чем другой)
poige
1

На самом деле это хорошая идея, когда вы обычно не имеете много данных /tmp, но иногда потребляете бесконечные гигабайты в течение ограниченной продолжительности. Проблема в том, что система свопинга в Linux не знает достаточно о вашем сценарии использования, чтобы сделать это правильно. Как правило, приоритет отдается дампу или обмену кешем на страницах программы, но это не очень помогает. Может быть возможно использовать cgroups для достижения вашей цели, это когда чистые данные хранятся в памяти программ, но я не уверен, как настроить cgroups в этом случае (я полагаю, вы могли бы использовать FUSE tmpfs ...) , К счастью, это не обязательно. Вы можете получить желаемое поведение с Zram и устройство поддержки.

zram-initэто программа, которая автоматизирует настройку zram, который является сжатым блочным устройством. Обычно в zram-initконфиге есть пример для монтирования /tmpкак zram. Это будет что-то вроде следующего

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

Это сожмет и сохранит в памяти все, что записано в / tmp. Обычное сжатие составляет где-то около 50%. Он потребляет максимум 2 ГБ физической памяти. Если ему не хватает физической памяти, он возьмет самые старые файлы и вставит их в резервное устройство, все еще сжатое. Обратите внимание, что при сжатии и распаковке файлов возникают некоторые накладные расходы процессора, но обычно это компенсируется уменьшением ввода-вывода.

Аналогичная настройка может использоваться в сочетании с cgroups, чтобы позволить некоторым процессам поменяться местами, не оказывая негативного влияния на общую производительность системы.

Perkins
источник