Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.
tmpfs
Файловая система, живущая в виртуальной памяти (RAM+swap). Много чего не умеет, но как простая/быстрая ФС для некритичной информации — вполне.
Ниже приведены подобранные на скорую руку выдержки из обсуждения применимости в sisyphus@.
вообще
> > По сути дискусси – я не понял самого главного> > – какая цель приследуются при переводе /tmp под tmpfs ?> > (предпологаю повышения быстродействия системы ?)
Насколько понимаю, мало кто делает выделенный раздел /tmp.
Таким образом, он оказывается на корне (мало кто делает
bind mount /var/tmp туда, а те немногие — уже ходили
в багзилу с жалобами на mount).
Отсюда забитие /tmp порождает забитие / со всеми вытекающими.
Выход: отрезать отдельный раздел, который будет преимущественно
"гулять", или снизить использование /tmp.
Первый вариант реализуется /tmp на tmpfs, которая живёт в RAM+swap;
увеличив своп на размер потенциально выделенного под отдельный /tmp
дискового пространства, получаем одним байтом двоих зайцев:
когда нужен своп, это место будет использовано под него; когда нужен
/tmp — под него.
Более динамическое использование ресурса — ср. с необходимостью
забивать руками при сборке ядра выделение памяти под page cache
в OpenBSD несколько лет тому против линуксового динамического.
> > – в каких случаях это реально повышает быстродействие,> > а в каких нет ?
В тех, когда работа с временными файлами напряжённая.
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически> повлияет на сервер/кластер работающий с 80 гигабайтами> временных файлов в /tmp? Правильно я понимаю, что в таком> случае ни о каком /tmp на tmpfs не может идти речи?
Скорее да.
> А когда может? Когда начинает расти производительность, а когда> – падать? Кто-нибудь вооще это мерял?
Можно попробовать поставить такой эксперимент (тут тоже по 80Gb
в /tmp при RAM 8Gb), но мне почему-то кажется более осмысленным
на такие /tmp совать reiserfs -o notail,noatime.
Возможно, потому, что баланс объёма данных и типичной работы
с ними тут скорее отличается от "положить одну исошку" или даже
"собрать kde".
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на > сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно > я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А > когда может? Когда начинает расти производительность, а когда – падать?
Зависит от характера работы.
Типичный для сборочного сервера характер работы такой:
– несколько гигабайт RAM;
– tmpfs на 8*N гигабайт (где N – это число параллельных сборок);
около 8G нужно для сборки OOo, остальным надо меньше;
– swap размером 2*RAM+sizeof(tmpfs).
При этом производительность заметно выше чем если бы сборка велась
на обычной файловой системе. Разумеется, чем больше занят swap, тем ниже
выигрыш в производительности.
Что касается падения производительности, то при наличии достаточного
свободного места в swap'е я этого падения не замечал. Мне _кажется_,
что этого свободного места должно быть не меньше чем размера RAM.
Ну и, конечно, необходимо помнить, что 64-битное ядро поддерживает tmpfs
лучше чем 32-битное. Особенно это заметно, когда на tmpfs очень много
файлов, которые суммарно занимают много места.
> Кто-нибудь вооще это мерял?
Я попробую специально замерить производительность в ситуации, когда
заполненная часть tmpfs больше размера RAM в 4, 8, 16, 32, 64, 128 раз.