У меня есть сервер Linux и запасной раздел на 500 ГБ. Я хотел отформатировать его и использовать для / tmp. Сервер иногда выполняет некоторые большие задачи по обработке данных, поэтому может случиться так, что / tmp будет содержать ГБ временных данных.
Тогда у меня возникла идея, что вместо этого я могу добавить его как раздел подкачки и смонтировать / tmp в tmpfs. Разумна ли эта идея?
Сервер имеет 6 ГБ ОЗУ, поэтому в большинстве случаев данные в / tmp будут только в ОЗУ с очевидным преимуществом в скорости. Вопрос в том, что, если на / tmp будет, скажем, 10-20 ГБ данных, как будет работать система? Какова будет производительность по сравнению с простым монтированием / tmp в раздел ext4? Спасибо за помощь.
Редактировать: Понятно, что система начнет выгружать память, когда использование tmpfs достигнет предела ОЗУ. Но достаточно ли умен Linux, чтобы выгружать данные tmpfs и хранить «обычные» данные в ОЗУ? Если да, то, полагаю, он мог вести себя разумно. Если нет, то серьезно пострадает вся система.
Это НЕ хорошая идеяTM.
Вы будете в порядке с большим /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). Это будет значительно быстрее, чем иметь дело с машиной, которая SWAPing
На самом деле это хорошая идея, если у вас обычно не так много данных в /tmp, но иногда потребляют бесконечные гигабайты в течение ограниченного времени. Проблема в том, что система подкачки linux недостаточно знает о вашем варианте использования, чтобы делать это правильно. Обычно он отдает приоритет сбросу или замене кеша над страницами программы, но это не очень помогает. Возможно, для достижения вашей цели можно использовать cgroups, это когда рабочие данные хранятся в памяти программы, но я не уверен, как настроить cgroups в этом случае (я полагаю, вы могли бы использовать FUSE tmpfs ...) . К счастью, этого не требуется. Вы можете добиться желаемого поведения с помощью zram и вспомогательного устройства.
zram-init это программа, которая автоматизирует настройку zram, который представляет собой блочное устройство со сжатым ОЗУ. Обычно есть пример в zram-init конфиг для монтирования /tmp как зрам. Это будет примерно так
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 ГБ физической памяти. Если ему не хватает физической памяти, он берет самые старые файлы и помещает их на устройство резервного копирования, все еще сжатые. Обратите внимание, что при сжатии и распаковке файлов возникают некоторые накладные расходы ЦП, но обычно это компенсируется сокращением операций ввода-вывода.
Аналогичную настройку можно использовать вместе с контрольными группами, чтобы разрешить обмен определенным процессам без отрицательного влияния на общую производительность системы.
Это могло быть разумной идеей.
Размещение фактической файловой системы в / tmp влечет за собой накладные расходы, потому что файловые системы делают все возможное, чтобы гарантировать, что данные на диске не будут повреждены в случае сбоя системы. Для файла / tmp, который очищается во время загрузки, это явно накладные расходы. Использование tmpfs позволит избежать этих накладных расходов.
С другой стороны, файловые системы также следят за тем, чтобы файлы были организованы на диске таким образом, чтобы оптимизировать время доступа, т. Е. Избежать фрагментации. Типичный последовательный доступ к файлам (в большинстве случаев) приводит к последовательному доступу к диску, который более эффективен, чем случайный доступ. Этот эффект более выражен на вращающихся жестких дисках, чем на SSD. Комбинация swap + tmpfs не может легко сделать это, потому что swap не знает, какая часть памяти принадлежит какому файлу, а tmpfs не знает, как страницы отображаются в физической памяти или на диске. Однако для больших файлов он должен работать хорошо, поскольку и tmpfs, и swap в этом случае пытаются сохранить непрерывность. По крайней мере, до тех пор, пока в подкачке много свободного места (в противном случае начинается фрагментация) и записи происходят достаточно медленно, чтобы у них был шанс быть выгруженным.
Итак, суть в следующем: это зависит от обстоятельств, вам следует попробовать оба варианта, чтобы увидеть, какой из них работает лучше всего.
Когда вы монтируете tmpfs, не забудьте явно указать размер. По умолчанию это половина физической памяти, поэтому всего 3 ГБ.