Вход:  Пароль:  
FreeSource: AltLinux/Dokumentacija/TmpFS ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на 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".

http://lists.altlinux.org/pipermail/sisyphus/2007-March/095099.html

для сборки

> Вот-вот. В чем идея-то?? И как реализация на 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 раз.

ldv@


Страницы, ссылающиеся на данную: ALTLinux/Dokumentacija/Hasher/Speed


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]