LINUX.ORG.RU
ФорумTalks

[speed it up] Хочу держать корневую ФС в памяти.


0

0

Последнее время стал замечать всё растущий негативный эффект от интенсивного использования винчестеров: запуск приложений длится секунды, иногда достигает десяти, двадцати секунд. Но если я запускаю приложение, значит это зачем-то надо...

Эту проблему нужно решать. Пока что прикидываю возможность использования гигабайтного -- полуторагигабайтного RAM-раздела с Reiser4 на борту. А снимок этого счастья записывать на диск при выключении... Беглый просмотр документации не дал ответа на вопрос об ограничении на размер этого диска (/dev/ram, конечно)

Другой, более простой, вариант - копировать пол-системы в TmpFS. и монтировать это счастье как часть корня... Но, опять-же, встаёт вопрос синхронизации с диском.

Может кто подскажет менее кривое решение, статьи, идеи? :)

//Докупить и третий, и чётвёртый гигабайты - не проблема.

Ответ на: комментарий от wyldrodney

>Хуже.

Меня больше всего вот что интересует: зачем тебе журналируемая ФС? Что, боишься что электричество вырубят и данные потеряются?

Place-des-Arts
()

у меня было так:

в tmpfs грузится root.sfs (squashfs)
на диске же есть каталог для записи изменений ФС
он объединяется с монтированным root.sfs в каталог, который используется как rootfs.

всё это элементарно сделано в
/etc/initramfs-tools/scripts/
и в
/etc/initramfs-tools/hooks/


да. кстати, таким же макаром я ставил линукс на FAT32. А можно, говорят, и на NTFS.

щас с диска root.sfs в tmpfs не грузится, он лежит теперь на рейде из 2x CF-133x

scaldov ★★
()
Ответ на: комментарий от GreyDoom

>http://www.linuxfocus.org/Russian/July2001/article210.shtml

Ничего нового :)

Я могу сам сделать мегакостыль, который будет работать, и довольно быстро. Но это будет именно костыль, что некрасиво.

Посему буду рад всяческим HOWTO и документации.

wyldrodney
() автор топика
Ответ на: комментарий от wyldrodney

>Мне нужна ФС со сжатием. ;) И не BtrFS.

Напишешь потом про то, насколько всё в реале ускорилось. Уже интересно. 40 секунд ты потеряешь на загрузке(чтение 1,5 гб в память), весьма толстую часть ресурсов ты потеряешь на обеспечение сжатия, а получишь ускорение на операциях с корнем во время работы - и насколько эти операции вообще часты?

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

Place-des-Arts
()
Ответ на: комментарий от scaldov

>на диске же есть каталог для записи изменений ФС

Я верно понимаю, что изменения в /usr/lib, к примеру, в него не пишутся - только /tmp и /var?

wyldrodney
() автор топика
Ответ на: комментарий от Place-des-Arts

Я всё это понимаю. Но:

1) Эксперимент

2) Память дешёвая

3) Безусловный профит

4) Мата^W плюс^W пайтон ботать постоянно нельзя

wyldrodney
() автор топика
Ответ на: комментарий от f3ex

Если только использовать AuFS для объединения двух директорий. А есть ли возможность откладывать запись на одну из ФС?

wyldrodney
() автор топика
Ответ на: комментарий от wyldrodney

>Эксперимент

Вот и напишешь отчёт. Мне давно было интересно - дают ли рамдиски какой-нибудь эффект кроме психологического? На практике они практически нигде не используются кроме livecd.

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

Place-des-Arts
()
Ответ на: комментарий от Place-des-Arts

>За много лет развития, кеширование и оптимизация операций с диском ушли очень далеко, вряд ли можно так вот просто сделать что-то более крутое.

Чтение из tmpfs ~530MB/s. Повторный запуск того-же Gimp'a в обычной системе занимает 3-4 секунды минимум, AFAIK. Разница налицо. Да, запуск зависит не только от скорость чтения, но она - один из решающих моментов.

wyldrodney
() автор топика
Ответ на: комментарий от wyldrodney

Эксперимент и ПРОФИТ.

>1) Эксперимент
>2) Память дешёвая

>3) Безусловный профит


Поддерживаю. Сам подумывал о подобном. Я думал грузить initramfs, в котором лежат /bin, /sbin и /usr, а остальные директории подмонтировать с НЖМД. А не как обычно, временный корень в initramfs, потом монтируется основной корень на НЖМД, а initramfs выбрасывается. ramfs, насколько я понимаю, создаётся несколько не так, как ramdisk, не требуется создание блока ограниченного размера и создание в нём файловой системы. Грузиться это, действительно, будет долго, но можно мечтать, что потом работать быстро.

Camel ★★★★★
()
Ответ на: Эксперимент и ПРОФИТ. от Camel

Да. Пока идея такова:

* Один раздел на винте со снимком(можно и бэкап дополнительно запихать) ФС системы.

* При загрузке это счастье копируется в tmpfs. Всё содержимое корня висит в оперативке.

* При записи в корень(tmpfs) необходимо синхронизировать со снимком. Тут может помочь aufs.

Осталось продумать детали, удивиться количеству костылей и ненастраиваемости...

wyldrodney
() автор топика

>А снимок этого счастья записывать на диск при выключении...

глупость. Метеорит поблизости пролетит или баба Зина своим утюгом весь подъезд закоротит - и прощай все изменения.

jcd ★★★★★
()
Ответ на: комментарий от wyldrodney

>Чтение из tmpfs ~530MB/s.

А запись в /dev/null наверное и того быстрее. Может сконцентрироваться на более реальных задачах?

>Повторный запуск того-же Gimp'a в обычной системе занимает 3-4 секунды минимум, AFAIK.

А на необычной?

Place-des-Arts
()
Ответ на: комментарий от melkor217

>До сих пор думаю как заставить систему на шлюзе крутиться целиком в ОП.

А вот это кстати, вполне реальный юзкейс. Отключение дисков ради экономии питания. А логи отсылать по syslog куда-нибудь ещё.

Place-des-Arts
()
Ответ на: комментарий от wyldrodney

Так что ты собрался держать в памяти? Ведь не каждую минуту ставишь, компилишь. Ведь тот же /usr ничего записывать ненадо. А /var в любом случае придется держать на винте.

f3ex ★★
()

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

Gary ★★★★★
()

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

GAMer ★★★★★
()

>Пока что прикидываю возможность использования гигабайтного -- полуторагигабайтного RAM-раздела с Reiser4 на борту

а не проще preload поставить? :)

nu11 ★★★★★
()
Ответ на: комментарий от Place-des-Arts

>Может сконцентрироваться на более реальных задачах?

Предлагай.

>А на необычной?

Рано говорить - ета система костылей ещё даже не продумана.

wyldrodney
() автор топика
Ответ на: комментарий от f3ex

>Так что ты собрался держать в памяти? Ведь не каждую минуту ставишь, компилишь. Ведь тот же /usr ничего записывать ненадо.

Хочу чтобы было можно.

>А /var в любом случае придется держать на винте.

Глупости. Можно и в памяти - это раз, а два - логи можно вообще не писать.

wyldrodney
() автор топика
Ответ на: комментарий от Gary

>Если у тебя достаточно ресурсов, чтобы держать занятым полтора гигабайта мозга, а программы запускаются настолько медленно - что-то надо исправлять в системе, но точно не такими костылями.

Какой из шедулеров ты предлагаешь: Anticipatory, Deadline, CFQ, BFQ, V(R)&? :)

wyldrodney
() автор топика
Ответ на: комментарий от GAMer

>поискать способы заставить ядро не убирать нужные файлы из кэша

Мне нужно запустить Gwenview, к примеру, не ожидая 20 секунд. При условии что до ранее он не запускался.

wyldrodney
() автор топика
Ответ на: комментарий от nu11

>preload

desktop ~ # du -sh /usr/share/
397M    /usr/share/
desktop ~ #

С иконками он мне не поможет, к сожалению.

wyldrodney
() автор топика
Ответ на: комментарий от wyldrodney

может у тебя в /var не только логи, но и база храниться :)

f3ex ★★
()

подскажу идею:

* берем unionfs
* берем рамдиск
* корень монтируем ro, рамдиск rw
* корень монтируем unionfs смешивая рамдиск с ro корнем

далее на выключении сбрасываем изменения unionfs в корневую ФС. Если реализуешь это в виде нормально юзабельного скрипта и выложишь в общий доступ будет весьма и весьма интересно

iku
()
Ответ на: комментарий от wyldrodney

>Мне нужно запустить Gwenview, к примеру, не ожидая 20 секунд. При условии что до ранее он не запускался.

Возможно, проще запускать gwenview автоматом при старте и не закрывать никогда? Ты потратишь на это куда меньше 1,5G оперативки, и сколь угодно быстрый запуск не сравнится с переключением в уже открытое приложение.

Place-des-Arts
()
Ответ на: комментарий от iku

Выше уже была аналогичная идея, правда с aufs(суть - unionfs).

Может подскажешь документацию по этой теме? Знаю, инет большой, много чего есть, но конкретные статьи бы не помешали :)

wyldrodney
() автор топика
Ответ на: комментарий от Place-des-Arts

>Возможно, проще запускать gwenview автоматом при старте и не закрывать никогда?

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

melkor217 ★★★★★
()
Ответ на: комментарий от Place-des-Arts

>Возможно, проще запускать gwenview автоматом при старте и не закрывать никогда?

Не слишком это удобно.

wyldrodney
() автор топика
Ответ на: комментарий от melkor217

Целиком в ОЗУ.

>До сих пор думаю как заставить систему на шлюзе крутиться целиком в ОП.

Так ведь уже давно такие придуманы. HOWTO легко находятся на сочетания подобные "бездисковый маршрутизатор" или "бездисковая машина". Суть в том, что initramfs не меняет корневую ФС с ramfs'а на что-то на НЖМД. Просто загрузил и работает. Ядро и initramfs можно загрузить по сети или с флэшки. Логи, если нужно, можно писать на NFS.

Camel ★★★★★
()

может squashfs в lzma? Т.е. вжать весь корень в squashfs и потом его прям монтировать из initramfs. В итоге с диска читтаться будет всего пара сотен мегов.

redbaron ★★
()

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

pierre
()

Почему ещё никто не посоветовал Windows Vista? :)

AX ★★★★★
()
Ответ на: комментарий от redbaron

uswsusp и так lzf поддерживает

#dpkg-reconfigure -plow uswsusp

lzma очень будет долго сжимать большие обьемы

elipse ★★★
()
Ответ на: комментарий от wyldrodney

>Не слишком это удобно.

освой рабочие столы :)

станет мегаудобно

у меня на старте на одном рабстоле пускается то на другом се итп в итоге когда что-то реально становится нужно просто переключаюсь на нужный стол и работаю

перезагрузки редкие, потому сколько там приложение на другом рабочем столе после загрузки пускается - пофиг

iku
()
Ответ на: комментарий от iku

Я _не_ хочу использовать Gwenview как браузер файлов, хоть в нём это и реализовано достаточно удобно.

Есть идеи с использованием aufs/unionfs? Рад буду выслушать.

wyldrodney
() автор топика
Ответ на: комментарий от pierre

>для синхронизации использовался банальный hibernate

Разве его можно вызывать для синхронизации не только во время засыпания?

wyldrodney
() автор топика
Ответ на: комментарий от wyldrodney

>Есть идеи с использованием aufs/unionfs? Рад буду выслушать.

я же вроде изложил?

юнионфс позволяет монтировать два (или больше) разделов одновременно. один из них rw. rw раздел всегда перекрывает ro разделы.

итого создаем / из двух rw/ro

в стартовых скриптах копируем на ram(rw) то что должно пускаться быстро и оно всегда будет удерживаться в памяти (или в свопе, но это дело десятое). Все ИЗМЕНЕНИЯ в файловой системе так же будут удерживаться в памяти

затем при остановке компьютера эти изменения можно сбрасывать на диск оптом как было запрошено в первом письме.

таким образом тебе надо написать два скрипта:

1. который копирует в RAM раздел то что требуется ускорить

2. который копирует из RAM раздела те изменения с файловой системой которые произошли за сеанс работы

ну и идеально как-то мониторить это все на предмет "а вдруг за время работы RAM-диск переполнится?"

iku
()
Ответ на: комментарий от iku

>я же вроде изложил?

Прости, вас тут много, странных предложений тоже... сложно всех запомнить.

Да, идея с aufs пока мне нравится больше остальных.

Синхронизировать во время выключения я могу кучей способов, и aufs - не самый лучший.

Пока вижу задачу в синхронизации во время работы: записал в /opt что-нибудь, данные через какое-то время уже записаны на винчестер. Крупные изменения не предвидятся - порядка нескольких десятков мегабайт за весь период аптайма.

//Ботаю документацию к aufs.

wyldrodney
() автор топика

А в чем профит, если через некоторое время работы все используемые приложения и так будут в кэше?

madcore ★★★★★
()

Докупи один SAS контроллер и один SAS диск, это меньшая проблема.

phasma ★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.