LINUX.ORG.RU

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

А что, IMHO, tmpfs - правильно.
Делаем здоровый swap partition, и переносим /tmp в tmpfs.

yoush ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Чегото я не понял всей мазы ентой fs, может кто расскажет?

Spy ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Маза такая ( ИМХО самое полезное ).
Жмешь в mc enter на каком-нть архиве, он распаковывается в /tmp,
а потом ты копируешь его содержимое куда-нибудь.
С обычной /tmp
архив(диск) -> /tmp(диск) ( распаковка )
/tmp (диск) -> final destination (диск)

С tmpfs
архив(диск) -> /tmp(память) ( распаковка )
/tmp (пямять) -> final destination (диск)

Итого кол-во дисковых операций сокращено в двое.

anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Ну если только для того чтоб в mc на архивы давить, то это сильное преймущество:))
не говоря о том, что если памяти достаточно и есть свободные буфера то непосредственно до диска при обычном tmp дело вообще может не дойти, а если и доходит (sync) то не так быстро.

ifconfig ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

А что будет, если несколько пользователей решат одновременно
собрать по ядру (и, соотвественно, пораспаковывать оное средствами mc -
ну, чайники, положем, только что с FAR`а :) ) на машинке со,
скажем, 96 метрами памяти?

P.S. Sorry, не читал пока...

allter ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

2ifconfig:
вот чтоб не было sync и придумали tmpfs

ну ещё мелкие фичи, типа распределения по нескольким свапам

anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Тут уже пролетало, что с ext2 использование
tmpfs не имеет большого смысла.

anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Статью то уж прочитайте сначала...

speer ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

> А что будет, если несколько пользователей решат одновременно
собрать по ядру

Несколько рутов одновременно на одной машине? :)

Havoc ★★★★ ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

> Несколько рутов одновременно на одной машине? :)
Кто Вам сказал, что ядро должны собирать root-ы? :-)


anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Для mc оно как раз не актуально.
Hint: Have you plenty of RAM/Virtual RAM? Set the tar VFS memlimit to -1.

anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Давно искал shared memory с внутренней структурой, похожей на файловую.
Раньше приходилось каждый раз данные между процессами гонять:
запаковать-рапаковать-запаковать-распаковать-... А теперь все благополучно в фс ляжет
и времени на упаковку данных для передачи другим процессам не нужно.
ИМХО для этого tmpfs и создавалась.

nikita ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)

ivlad ★★★★★ ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

А может оно не надо было. Потому и не делали. А теперь добрый студент решил курсовик написать. И написал.

shuras ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

> Несколько рутов одновременно на одной машине? :)

По хорошему у root-а нет полномочий на сборки, он только инсталлирует :)

AffreuxChien ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Эх, если бы память в Unix-ах была одноуровневой, без жесткого разграничения ОЗУ/область данных/область swap - это было бы "оно".

Если бы ещё и приватную, для каждого процесса TMPFS - вообще "самое оно".
А так - несколько опасная штука...

AffreuxChien ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Для непонимающих зачем оно.
Слава богу, что никто не знает кто я ;)
Symptom

Sie wollen den vorhandenen Hauptspeicher für SAP auf Linux effizienter

nutzen und dazu die Möglichkeiten des Linux Kernels 2.4 nutzen.


Weitere Begriffe

Memory Management, Linux

Ursache und Voraussetzungen

Mit dem Linux Kernel 2.2 muß das SAP System die User-Kontexte aller aktiven User gleichzeitig im Adressraum der Workprozesse eingeblendet halten. Das entspricht der klassischen UNIX-Implementierung des

Extended Memories (EM).


Die Summe aller gerade aktiven User-Kontexte ist damit durch die Adressraumbeschränkungen der Intel 32 Bit Plattform begrenzt. Konkret heißt das, daß maximal ca. 1,2 GB für alle User-Kontexte zusammen zur Verfügung stehen.


Lösung

Um mehr EM für die SAP User zur Verfügung zu stellen, bietet SAP auf der Basis des Linux Kernels 2.4 ab dem SAP Kernel 4.6D, Patchlevel 488, eine flexiblere EM Verwaltung.


Basierend auf dem TMP-Filesystem im Linux Kernel 2.4 kann der SAP Workprozess nun jeden gerade benötigten Userkontext einzeln in den Adressraum einblenden. Das bedeutet, daß nun ein einzelner Userkontext auf ca. 1,2 GB beschränkt ist. Die Summe der User-Kontexte kann jedoch bedeutend größer werden (im Prinzip nur begrenzt durch RAM + Swap). Dies ist völlig analog zum Memory Management unter Windows NT.


Sie können die neue EM-Verwaltung unter folgenden Voraussetzungen einsetzen:

1. Linux Kernel 2.4 mit dem TMPFS unter /dev/shm gemountet, s.u.

2. SAP Kernel 4.6D, Patchlevel 488 oder höher und

3. Im (Instanz-) Profil des SAP Applikationservers wird das oben beschriebene Verhalten aktiviert durch Setzung des Profilparameters: es/implementation = map


Weitere Parameter, die hier eine Rolle spielen, sind

em/max_size_MB (gibt die maximale Größe des EM an und sollte nicht so groß eingestellt werden, daß RAM + Swap erschöpft werden),
em/initial_size_MB (gibt die anfängliche Größe des EM an) und
em/address_space_MB (gibt die maximale Größe eines User-Kontexts an und wird bei Instanz-Start reserviert).


Falls die Linux-Distribution die passenden Einstellungen nicht

bereits setzt, können Sie auf der Betriebssystem-Ebene das TMPFS in folgender Weise einstellen:

4. Machen Sie folgenden Eintrag in das File /etc/fstab:

tmpfs /dev/shm tmpfs size=<size> 0 0


Die Angabe <size> sollten Sie entsprechend des verf&uuml;gbaren RAM + Swap einstellen. Wenn Ihre Maschine beispielsweise 4GB RAM und 8 GB Swap besitzt, so k&ouml;nnen Sie das TMPFS mittels

size=10G bzw. size=10240M

auf 10 Gigabyte begrenzen.

5. Mounten Sie das TMPFS:

mount /dev/shm

6. Pr&uuml;fen Sie, ob das unter /dev/shm gemountete TMPFS Platz meldet, damit die vorherigen Aktionen also gelungen sind:

df -h /dev/shm

anonymous ()

Мда, давай-те я что-ли по русски скажу зачем нужна эта tmpfs

Поправьте если я ошибаюсь.

Компиляция gcc без -pipe либо mc-tarfs (konquieror-non-l):

Цикл такой: создание, запись, чтение, удаление.
Так вот, собственно данные должны записаться на диск, так как содержат измененные данные кэша файловой системы. Если это не успело произойти до стирания файла, ничего страшного они просто перейдут в разряд измененного буфера блочного устройства. Вообщем-то можно надеяться, что этот кусок диска перепишется новыми данными, если забыть об организации записи в ext2. (Диск раделен на несколько частей (inodes,data) которые заполняются равномерно (помере возможности), тоесть поочереди). Про журналируемые fs я просто промолчу :)

p.s. В solaris такая организация /tmp есть (не знаю на сколько давно), почему бы не использовать это в леинукс.

Toster ()
Ответ на: Re: Статья о tmpfs на Linux от IBM DeveloperWorks от ivlad

Re: Re: Статья о tmpfs на Linux от IBM DeveloperWorks

2oxonian
>Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)

Во первых сделали давненько, года полтора назад.

Во вторых долго сомневались - стоит ли делать:
поскольку ext2 обгоняет tmpfs у Solaris на сравнимых
машинах ;P

Да и в солярке tmpfs появилась только из-за оооочень медленной
файловой системы.

anonymous ()
Ответ на: Re: Re: Статья о tmpfs на Linux от IBM DeveloperWorks от anonymous

Re: Re: Re: Статья о tmpfs на Linux от IBM DeveloperWorks

>>Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)
>
> Во первых сделали давненько, года полтора назад.
>
O! I pochemu tol'ko teper' etim stalo mozhno pol'zovat'sya? :)

> Во вторых долго сомневались - стоит ли делать:
> поскольку ext2 обгоняет tmpfs у Solaris на сравнимых
> машинах ;P
Ya ne razu benchmarki ne meryal, no dazhe pri "normal'nom" pol'zovanii
ya chto-to ni razu ne zamechal velikoj krutizny ext2 v tom chisle
i po skorosti.
>
> Да и в солярке tmpfs появилась только из-за оооочень медленной
> файловой системы.
nu konechno ufs tormoznee tmpfs, chto tut udivitel'nogo ?

ivlad ★★★★★ ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

2oxonian
>Ya ne razu benchmarki ne meryal, no dazhe pri "normal'nom" pol'zovanii

А на солярке работал ?

Ещё раз:
http://www.tux.org/lkml/#s9-12

anonymous ()

Re: Статья о tmpfs на Linux от IBM DeveloperWorks

Хммм ... а что если сделать ramdisk и на нем смонтировать /tmp ???

saper ★★★★ ()
Ответ на: Re: Статья о tmpfs на Linux от IBM DeveloperWorks от saper

Re: Re: Статья о tmpfs на Linux от IBM DeveloperWorks

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

1. Рамдиск забирает память у системы насовсем.
   В то время как тмпфс использует памятзь по потребности.

2. Размер рамдиска ограничен.
   тмпфс строго говоря тоже ограничен размерами физической памяти и свапа. параметр "size" указываемый команде mount ограничивает лишь
верхний предел.

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