тыц?

И тыц. Можно заюзать поиск ;) на welinux :)

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

Смотрим теги и делаем запрос

В результате находим хороший топик

чёрт, парсер порезал :(
Вот запрос, созданный по тегам, указанным автором
Вот что нашлось
ЧЯДНТ?

все, я понял. я везде неправ:)

Собственно пост правильный.
Как бы некоторые операции должны происходить быстрее
У меня, например в tmpfs монтируется следующее
tmpfs /var/run tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0


Ну к плюсам возможно стоит добавить "автоматическую отчистку" после выключения/перезагрузки компьютера.

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

FHS не обязывает очищать эти каталоги, но вообще рекомендует, но это не фатально. Очисткой может заниматься система.

Вообще с монтированием tmp в память я наткнулся на подводный камень в виде архивов в mc. Никто не знает, как с этим бороться?

Не до конца понял вас. Можете раскрыть тему подробнее?

Вот ниже TiGR уже написал :)

mc для просмотра архивов распаковывает его в tmp. Если в tmp не хватит места, архив в mc открыть не получится.

Это да. Согласен.

Просто, я думал, может есть способ заставить такие программы распаковывать в другие места?

А надо смотреть, как mc работает с архивами. Если есть возможность повесить там какой-нибдуь обработчик с помощью скрипта перед распаковкой то можно было бы как-то, скажем архивы больше 100 Мб распаковывать в другом месте.

А мне кажется, что это особо ни к чему, все буферируется/кэшируется практически на всю свободную, кроме возможно некоторых особых случаев, лучше оставить оперативку ядру, оно автоматом будет адаптироваться к смене типа нагрузок и выделять память туда, где нужнее.
Забрав кусок оперативки, мы уменьшаем способность ядра к адаптации.

Ты абсолютно прав, на серверах помещение в оперативку таким способом не дает видимого прироста производительности. На десктопе и так все работает неплохо.

Можно профиль FF смонтировать в tmpfs. Будет заметно быстрее.

Ну вот есть у меня 4Gb RAM. За два года эксплуатации я больше 2.5Gb еще не занимал. Ну и чего бы 1Gb не задействовать в качетсве tmpfs?

Можно я скажу, то, что думаю? Не ради поспорить. Думаю выигрыш будет мизерным, если вообще будет и не оправдает затраченного времени.

Суть не только быстродействием ограничивается.

Кстати, не думаю, что кэш стоит монтировать в оперативку. Так теряется весь смысл от его использования после перезагрузки
И, ЕМНИП, /var/tmp должен сохраняться между перезагрузками по FHS

действительно. убрал

Меня всегда в таких вещах смущала возможность переполнения размера временного каталога. Допустим, есть какой-то архив, и некая софтина по своей дури полностью его распаковывет в tmp. Допустим, файл - 5 Гб, а оперативы - 4 Гб. К чему это приведёт?

tmpfs /tmp tmpfs defaults,nosuid,size=1024M,mode=1777 0 0
ключевое слово size
если вы конечно про это имели ввиду

по хорошему это "ключевое слово" нужно везде по вставлять?

И? Получается, программы, которым нужно больше 1 Гб в папке tmp не смогут работать? Или если так получится, что несколько программ наполдят файлов на сумму более указанной в size - тоже произойдёт какое-то безобразие?

#du /tmp
...
36K total

аптаймы по ~неделе, больше ~50 Мб в tmp не видел, так что даже 1 Гб - для мой системы перебор.

Посмотрите часовой ролик на ютубе (или не часовой, но в HD качестве), и попробуйте в mc посмотреть внутренности большого архива.

И будет вам щастье. :)

всегда поражался людям, которым лучше меня известно, что мне нужно

А при чём тут ваши потребности? Изначально вопрос был в том - перенесение /tmp в tmpfs накладывает ограничения, или нет. Вопрос был - к чему это приведёт.

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

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

да, пардон.

вот цитата из wiki:
In small memory systems, locking too large tmp data in memory with the sticky bit may be used to cause system instability as temporary data grows

сейчас уберу у себя ограничение на размер и проверю.

а вообще более важен вопрос в целесообразности применения самой tmpfs, потому как ощутимых изменений в работе системы я не почувствовал (хотя конечно для программ, активно использующих /tmp - будет заметно)

насколько я помню, если на задавать ограничение то размер файловой системы будет 2 Гбайт

size: The limit of allocated bytes for this tmpfs instance. The
60 default is half of your physical RAM without swap. If you
61 oversize your tmpfs instances the machine will deadlock
62 since the OOM handler will not be able to free that memory.

# cat /etc/fstab | grep /tmp
tmpfs /tmp tmpfs defaults,nosuid,mode=1777 0 0

# /bin/df
Filesystem 1K-blocks Used Available Use% Mounted on
...
tmpfs 2028512 2028512 0 100% /tmp

mc: при попытке открытия tar.bz2
bzip2: I/O or other error, bailing out. Possible reason follows.
bzip2: No space left on device
Input file = (stdin), output file = (stdout)

tar.gz:
gzip: stdout: No space left on device

zip:
содержимое архива показывает, при копировании файла - файл все время получается 0-размера

ну и попробовал посмотреть видео с Youtube:
flash ошибок не показывает, но и ничего не играет

в общем все зависит от того насколько корректно разработчики той или иной программы обрабатывают исключительные ситуации

память в системе не кончится, но воспользоваться 2 Гб, занятыми tmpfs уже не получится

меня вот смущают папки:
ниче страшного, что они после перезагрузки будут очищаться? че там вообще хранится то?

В /var/run обычно лежат pid файлы с идентификаторами процессов.
В /var/lock файлы блокировок.

Все это нужно только тогда когда процессы работают.

т.е. можно монтировать, он заново при загрузке все создаст?

не при загрузке даже, а при запуске этих процессов

Да.

а после s2disk, интересно, всё нормально будет работать?

а, ну и какой размер можно указать, я тут смотрю совсем не много им надо, но вот примерный предел интересен:

> sudo du -sh /var/lock/
32K /var/lock/
> sudo du -sh /var/run/
256K /var/run/
> uptime
14:05pm up 25 days 20:33, 7 users, load average: 0.08, 0.09, 0.03


после монтирования

apache дает ошибку при запуске:
# /etc/init.d/apache2 start
* Starting web server apache2
(2)No such file or directory: apache2: could not open error log file /var/log/apache2/error.log.
Unable to open logs

а вы не забыли создать каталог /var/log/apache2 ?

так он /var/log/ после перезагрузки каждый раз сбрасывает. смысл создавать?

а смысл тогда апачу писать лог в не созданный каталог ? :D

и вообще идея хранить логи в tmpfs мне не кажется очень хорошей

я тоже так подумал, щас удалю:)

mkdir /var/log/apache2/

...и не перезагружаться! Даешь 100% Uptime!

Имхо нужно просто брать и тестировать, повышается ли производительность.
А бездумно сувать в оперативку все подрят не стоит.

у меня только 2 примера когда вынос папки в опеативку дал существенный прирост

1) есть 4 очень мощьных SMTP сервера в сутки проходит порядка 2 миллиона писем не считая спама, почтовые очереди постфикса в оперативке ускорили систему в разы.

2) Gentoo при сборке на 4х ядеринках и выше тоже дает хороший прирост сборки если /var/tmp перенести в оперативку.

но тогда пропадает смысл в ccache, который иногда очень даже кстати.

env | grep CCACHE
CCACHE_SIZE=2G
CCACHE_DIR=/u02/var/ccache

его можно и подвинуть
пирост есть и очень хороший.