[NIXP] Fedora 18 будет хранить временные файлы из /tmp в оперативной памяти

[Dmitry Shurupov]

Предложение Леннарта Поттеринга (Lennart Poettering) и Кэя Сиверса (Kay Sievers) по использованию файловой системы tmpfs для системной директории /tmp было принято для релиза Fedora 18. Комитет FESCo (Fedora Engineering Steering Committee) сообщил о принятии tmpfs в качестве файловой системы по умолчанию для каталога /tmp в релизе Fedora 18 (состоится в конце 2012 года). Это означает, что основное хранилище для временных файлов системы переместится с жесткого диска в оперативную память. Среди преимуществ такого подхода авторы идеи называют следующие: меньшая нагрузка (ввод/вывод) на жесткий диск, увеличение времени жизни SSD-дисков, а также небольшой выигрыш в энергопотреблении и производительности. Тенденция перехода на tmpfs для /tmp наблюдается и среди других Linux-дистрибутивов: так уже в ArchLinux, будет в следующем релизе Debian и ожидается в Ubuntu 12.10.

оригинал на www.nixp.ru

[BURF]

хорошо, потом вообще всю систему можно будет в оперативке крутить, для быстроты

[alv]

Вообще-то, все разумные люди в твёрдой (оперативной) памяти лет 10 как монтируют в /tmp tmpfs.

[watashiwa_daredeska]

все разумные люди в твёрдой (оперативной) памяти лет 10 как монтируют в /tmp tmpfs.

10 лет назад у моих машин еще не было столько оперативной памяти, а меня душила слишком большая жаба, чтобы прикупить планок для tmpfs. :)

[alv]

10 лет назад у моих машин еще не было столько оперативной памяти

Лет 10 назад и у системы с приложениями не было столько жабы до памяти.
Вообще практика показала, что в каждый исторический момент оптимальное количество памяти - то, которое можно купить за 100 баксов

[FlySnake]

Вообще-то, все разумные люди в твёрдой (оперативной) памяти лет 10 как монтируют в /tmp tmpfs.

Пробовал год назад делать это. Разницы в скорости работы проблемных приложений замечено не было.

[Janik]

хорошо, потом вообще всю систему можно будет в оперативке крутить, для быстроты

Уже есть: Puppy Linux, Puppyrus

[alv]

Разницы в скорости работы проблемных приложений замечено не было.

А разнице в скорости работы приложений и взяться некуда.
Есть разница, например, в скорости компиляции, если в /tmp собирать все временные продукты оной.
Разница, кстати, небольшая, процентов 10. А на нынешних многопроцессорных камнях - может, и вообще незаметна.
А поскольку нынче мало кто компилирует - то Ленни вовремя спохватился

хорошо, потом вообще всю систему можно будет в оперативке крутить, для быстроты

Уже есть: Puppy Linux, Puppyrus

Минимум половина всех существующих LiveCD, со времён старика Knoppix'а, позволяют скэшировать себя в RAM.
А уж сколько веков технологии ram-дисков - и летописцы не припомнят.

[watashiwa_daredeska]

Разница, кстати, небольшая, процентов 10. А на нынешних многопроцессорных камнях - может, и вообще незаметна.

Нестыковочка. Чем больше скорость процессора, тем большую долю занимают дисковые операции, тем сильнее выигрыш от их оптимизации (в процентах).

[NickLion]

Вообще-то, все разумные люди в твёрдой (оперативной) памяти лет 10 как монтируют в /tmp tmpfs.

Зачем? Ускорение не особо заметно (кеш в памяти и так есть), если вообще есть. А зачем мне видео с youtube (которые складываются в /tmp) в памяти? Чтобы потом это всё свопилось на диск? Теоретически образы дисков для записи тоже в /tmp будут сваливаться (на практике приводом уже достаточно долго не пользуюсь). Объясните мотивацию.

Для SSD — да, вполне логично не портить устройство зря, но лично я просто выделил бы /tmp в раздел на винте и всё.

[alv]

Нестыковочка.

Поясняю. Написано незаметна.То есть 10% от часа - 6 минут. Это заметно. А 10% от 10 секунд - это 1 (одна) секунда. И это незаметно.

[alv]

Объясните мотивацию.

Я кого-то в чём-то убеждаю, чтобы мотивировать?
И кстати, никакие ютутбы и образы у меня в /tmp не сваливаются. И на диск ничего не свопится.
На текущий момент весь мой /tmp:

Код: Выделить всё

$ du /tmp
...
20K     /tmp

[NickLion]

Ну, фраза "все разумные люди в твёрдой (оперативной) памяти" на мой взгляд подразумевает целесообразность сего действа, наличие веских причин для этого. Вот и интересно было, что я упустил.

А по поводу youtube, а куда у Вас складывается кеш видео в режиме html5?

# du -hs /tmp

269M /tmp

[watashiwa_daredeska]

а куда у Вас складывается кеш видео в режиме html5?

В ~/.cache либо в ~/.mozilla/firefox/*/Cache, либо еще где в ~.

[alv]

а куда у Вас складывается кеш видео в режиме html5?

В ~/.cache либо в ~/.mozilla/firefox/*/Cache, либо еще где в ~.

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

[alv]

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

Во-первых, простая логика: всё, что не должно пережить перезагрузку, резонно хранить в памяти, чтобы не думать после сбоя, очистился /tmp или нет. Кстати, 10 лет назад очится /tmp при нормальной перезагрузке вовсе не подразумевалась по умолчанию.
Во-вторых, 10 лет назад разницу при компиляции в tmpfs и на block based разделе действительно можно было заметить. Особенно во FreeBSD при пересборке ядра и мира - там правда не tmpfs, а mfs, но принцип тот же.

[NickLion]

а куда у Вас складывается кеш видео в режиме html5?

В ~/.cache либо в ~/.mozilla/firefox/*/Cache, либо еще где в ~.

~/.cache — это правильно, побольше бы программ этому следовали, а вот остальные варианты ("либо еще где в ~") совсем не вдохновляют. Ну, а Konqueror в /tmp сваливает. Не худший вариант.

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

Во-вторых, 10 лет назад разницу при компиляции в tmpfs и на block based разделе действительно можно было заметить.

А сейчас? Надо будет сравнить, может профит и вправду есть и файловый кеш не настолько хорош.

[watashiwa_daredeska]

Ну, а Konqueror в /tmp сваливает. Не худший вариант.

Худший.

[NickLion]

Почему? Да, я согласен, что ~/.cache — это оптимальный вариант. Но чем /tmp хуже ~/.mozilla/...; ~/.opera/... ~/. ?

[sash-kan]

/tmp хуже ~/.mozilla/...; ~/.opera/... ~/.
чем?
чем ~/.mozilla/...; ~/.opera/... ~/.

ваш кэп

[watashiwa_daredeska]

чем /tmp хуже ~/.mozilla/...; ~/.opera/... ~/. ?

* Непостоянством.
* Если машина многопользовательская, то необходимо выдать на эту помойку приличный объем, чтобы кэш всех пользователей мог влезть в один несчастный /tmp. А возможно, что не только в случае многопользовательской машины. У меня одного, например, 3 активных профиля браузера.
* Это просто нелогично. Чем видео так сильно отличается, что кэш видео должен лежать не в кэше, а хрен знает где?

[drBatty]

А может мне кто-нибудь объяснит такую не стыковку:
1. имеем систему где МНОГО памяти. Я создаю временный файл (не важно где), если этот файл действительно _временный_, то он дальше дискового кеша не пройдёт: не успеет записаться на диск. Отложенная запись работает, система отвечает приложению, что файл создан, однако на самом деле он ещё в кеше. Потом мы туда что-то записываем/читаем, а потом удаляем. Всё это происходит быстро, и временный файл до диска не доходит. В этом случае, я не очень понимаю, зачем нужна ramfs для временных файлов? Всё равно, они на диск НЕ пишутся. В чём тут фишка?
2. Мы имеем систему где памяти недостаточно много, и её не всегда хватает. Но в такой системе, мы должны выбрать объём /tmp в точности такой, как он нам нужен. Т.е. если памяти мало, то её должно быть мало И в /tmp И в остальной системе. Иначе возникнет ситуация, когда в /tmp место кончается, за то в остальной системе свободного места полно. Или наоборот. В любом случае, это приведёт к вытеснению чего-то нужного в swap, и как следствие, к замедлению на несколько порядков. Ну а выбрать точно ровно столько, сколько нужно, очевидно невозможно - сейчас нам нужен /tmp, а через 5 минут мы будем делать временные файлы в ~/.mozilla.

Так в чём же фишка?

[alv]

Так в чём же фишка?

фишка в том, что tmpfs - не ramdisk и не дисковый кэш.
Простой пример: нужно скопилять что-то грандиозное, типа ядра и мира во FreeBSD, или типа Иксов, OOo или KDE где угодно.
Монтируем в /tmp tmpfs или mfs соответственно, делаем там каталог /tmp/чего_надо/obj и задаём его как путь для объектных файлов. Получаем тот самый профит - в противном случае они писались бы на диск, а ни в какой не дисковый кэш. Если памяти вдоволь, ни до какого свопа дело не дойдёт. Если дойдёт - во Free это будет всё равно выгодней, там механизм свопирования другой, нежели в Линуксе.
Опробовано многократно и во Фре, и в Линуксах типа Gentoo и LFS.

Но в такой системе, мы должны выбрать объём /tmp в точности такой, как он нам нужен.

/tmpfs не выбирается в точности такой, как нужно - ставится просто верхний лимит, например, 30% от RAM. То есть за 30% объём её не перевалит. Но если в данный момент в /tmp сидит... ща гляну, сколько у меня там сидит в /tmp:

Код: Выделить всё

~[alv]=> du /tmp
...
20K     /tmp

то она и отъедает от моих 4 Гбайт ровно 20К - и ни байтом больше. По top'у - 3078016k used
Копирую туда изошник на 700М с копейками -

Код: Выделить всё

~[alv]=> du /tmp
...
730M    /tmp

Памяти 3821280k used
Удаляю из /tmp изошник: памяти - 3100352k used
Вот вам и профит: когда tmpfs не нужна - она есть не просит. Но когда понадобится - под рукой.

[drBatty]

Монтируем в /tmp tmpfs или mfs соответственно, делаем там каталог /tmp/чего_надо/obj и задаём его как путь для объектных файлов. Получаем тот самый профит - в противном случае они писались бы на диск, а ни в какой не дисковый кэш. Если памяти вдоволь, ни до какого свопа дело не дойдёт.

если памяти вдоволь, и дисковая подсистема занята постоянным чтением(т.к. современные CPU очень быстро компилируют, а вот быстродействие HDD увеличилось не настолько сильно), то будет-ли у дисковой подсистемы свободное время, что-бы сбросить obj файлы на диск? И даже если будет, то зачем системе стирать эти файлы из дискового кеша, ведь памяти вдоволь?

Если дойдёт - во Free это будет всё равно выгодней, там механизм свопирования другой, нежели в Линуксе.

вот про BSD - я без понятия.

Опробовано многократно и во Фре, и в Линуксах типа Gentoo и LFS.

не знаю как во фряхе, но вот в линуксе, obj файлы всё равно потом при линковке надо в RAM ВСЕ грузить, потому, если памяти не вдоволь, то процесс линковки может растянуться на долгие часы, если не дни, ну а во время компиляции расход памяти незначительный. Проверял на сборке FireFox при 1Гб и при 1.5Г. При этом сам процесс линковки требует примерно 1Гб, и если свободной памяти меньше, то всё ЖУТКО замедляется, хотя при компиляции можно комфортно работать (особенно если выставить небольшой положительный nice для make). Т.е., если памяти достаточно много, то obj файлы всё одно остаются в кеше, и потому дополнительное время на их загрузку не требуется. Ну а если памяти не хватает, то собрать всё равно не получится (ну лично меня достало ждать больше 10 часов, ИЧСХ, при этой линковке работать просто невозможно).

/tmpfs не выбирается в точности такой, как нужно - ставится просто верхний лимит, например, 30% от RAM. То есть за 30% объём её не перевалит. Но если в данный момент в /tmp сидит... ща гляну, сколько у меня там сидит в /tmp:

какая разница, сколько "сейчас"?

Вот вам и профит: когда tmpfs не нужна - она есть не просит. Но когда понадобится - под рукой.

а если вам надо больше 30% в tmp? лезем в своп? А у меня - никуда не лезем, юзаем дальше общую память.

ЗЫЖ в волшебные свойства свопа в фри верится с трудом - очень сильное колдунство. Впрочем - это ИМХО.

[Ali1]

Если я не путаю, то вытеснение в swap дешевле записи в ФС.

[drBatty]

Если я не путаю, то вытеснение в swap дешевле записи в ФС.

дешевле. но при переполнении ramfs запись в swap будет в _любом_ случае, а вот запись из дискового кеша будет далеко не всегда, а лишь при его переполнении, или если системе нечем заняться. Очевидно, что размер дискового кеша намного больше ramfs, потому-что под него выделяется _вся_ свободная память.

Ну и запись в своп хоть и дешевле, но не сильно намного. Максимум 5..10%. По любому: например у нас 3Гб, 1Гб займёт система, 1Гб займёт кеш, и 1Гб займёт ramfs, которая /tmp, для временных файлов. Я всё равно не понимаю, почему не отдать этим временным файлам все 2 свободных гигабайта? Единственное возражение - если у нас SSD или флешка. Тут да, во время простоя, система будет скидывать на этот /tmp свои временные файлы, а число циклов записи на SSD ограничено. Возможно в этом особом случае есть смысл насильно заставить систему сохранять файлы именно в ОЗУ. Хотя с другой стороны, ИМХО это временная мера, т.к. число циклов записи на SSD уже сейчас достаточно велико, и дальше будет только увеличиваться. Ну и кроме того, далеко не у всех сейчас всего один накопитель, да и тот - SSD. Ну а к тому времени, как у всех будет _только_ SSD, проблема числа циклов записи ИМХО уже отойдёт в прошлое. ИМХО федора опять бежит впереди паровоза, заделывая делянку под будущую RHEL.

[sgfault]

Так в чём же фишка?

фишка в том, что tmpfs - не ramdisk и не дисковый кэш.
Простой пример: нужно скопилять что-то грандиозное, типа ядра и мира во FreeBSD, или типа Иксов, OOo или KDE где угодно.

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

Если я не путаю, то вытеснение в swap дешевле записи в ФС.

дешевле. но при переполнении ramfs запись в swap будет в _любом_ случае, а вот запись из дискового кеша будет далеко не всегда, а лишь при его переполнении, или если системе нечем заняться. Очевидно, что размер дискового кеша намного больше ramfs, потому-что под него выделяется _вся_ свободная память.

Ну и запись в своп хоть и дешевле, но не сильно намного. Максимум 5..10%. По любому: например у нас 3Гб, 1Гб займёт система, 1Гб займёт кеш, и 1Гб займёт ramfs, которая /tmp, для временных файлов. Я всё равно не понимаю, почему не отдать этим временным файлам все 2 свободных гигабайта?

А если просто выделить под tmpfs 2гб? Тот 1гб, что отдан кэшу, будет передан tmpfs, или лишний 1гб tmpfs уйдет в своп?

[alv]

а если вам надо больше 30%

Можно не ограничивать вообще. Я, например, не ограничиваю

Если я не путаю, то вытеснение в swap дешевле записи в ФС.

Не путаешь

[alv]

при переполнении ramfs запись в swap будет в _любом_ случае, а вот запись из дискового кеша будет далеко не всегда, а лишь при его переполнении

При переполнении ramfs запись будет всегда, а запись из кэша - только при его переполнении.
Блеск!
И не путайте таки ramfs и tmpfs, это разные вещи.

будет "ага".

А от любого "ага" только интенсивное использование /dev/head помогает, иначе может произойти перенаправление >> /dev/ass.

[Ali1]

Код: Выделить всё

[ali@f16 ~]$ free
             total       used       free     shared    buffers     cached
Mem:       8177836    3342444    4835392          0     185168    2038704
-/+ buffers/cache:    1118572    7059264
Swap:     16684224          0   16684224
[ali@f16 ~]$ sudo dd if=/dev/zero of=/media/out bs=1M count=512
512+0 записей считано
512+0 записей написано
 скопировано 536870912 байт (537 MB), 0,566466 c, 948 MB/c
[ali@f16 ~]$ free
             total       used       free     shared    buffers     cached
Mem:       8177836    3868268    4309568          0     185208    2562996
-/+ buffers/cache:    1120064    7057772
Swap:     16684224          0   16684224
[ali@f16 ~]$ sudo rm /media/out
[ali@f16 ~]$ free
             total       used       free     shared    buffers     cached
Mem:       8177836    3342972    4834864          0     185216    2038708
-/+ buffers/cache:    1119048    7058788
Swap:     16684224          0   16684224
[ali@f16 ~]$

Since tmpfs lives completely in the page cache and on swap, all tmpfs
pages currently in memory will show up as cached. It will not show up
as shared or something like that. Further on you can check the actual
RAM+swap use of a tmpfs instance with df(1) and du(1).

/usr/share/doc/kernel-doc-3.3.0/Documentation/filesystems/tmpfs.txt