From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 18 Mar 2007 21:00:53 +0200 From: Michael Shigorin To: ALT Linux Sisyphus discussion list Message-ID: <20070318190052.GX13731@osdn.org.ua> Mail-Followup-To: ALT Linux Sisyphus discussion list References: <200703161526.53469.iadzhubey@rics.bwh.harvard.edu> <20070318082439.GC13731@osdn.org.ua> <200703181321.41181@ruslandh> <200703181344.33977.iadzhubey@rics.bwh.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200703181344.33977.iadzhubey@rics.bwh.harvard.edu> User-Agent: Mutt/1.4.2.1i Subject: [sisyphus] tmpfs usage X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: shigorin@gmail.com, ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2007 19:00:54 -0000 Archived-At: List-Archive: List-Post: On Sun, Mar 18, 2007 at 01:44:33PM -0400, Ivan Adzhubey wrote: > > > Засуньте на tmpfs, если памяти хватает > > Вот - это самый интересный вопрос - какая должна быть память, какой Swap > > и какой размер отвести под /tmp для записи двухслойного DVD, например > > через K3b, который по-умолчанию кладёт образ в /tm/.private.. :) > Ну наконец-то хоть кто-то меня поддержал ;-) А то дискуссия > стремительным домкратом ушла в направлении обсуждения > /tmp/.private, то есть мелких деталей, которые меня пока не > интересуют совершенно, а на мои вопросы, с которых этот тред > начался, господа разработчики забили. Простите, там получился перевязанный пучок трёх проблем: - /tmp/... vs /home/.../tmp - tmpfs vs filesystem - сервер vs десктоп > > По сути дискусси - я не понял самого главного > > - какая цель приследуются при переводе /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". -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/