Re: tmpfs mit wenig RAM

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Sun, 2 Dec 2012 15:49:40 +0100 (CET)

Erik Niemeyer <erik(at)3w20.de> wrote:
> Ist es sinnvoll /tmp als tmpfs im RAM anzulegen, wenn man nur 4 GB
> physikalisches RAM hat?

"Nur"?
Ich habe das schon auf Rechnern mit 1 GB RAM gemacht, und
in einem Fall hatte die Kiste sogar nur 256 MB RAM.

Aber es kommt natürlich auf den Einzelfall an. Wenn man
auf einem Rechner Software laufen hat, die sehr viele
Daten in /tmp ablegt, muss man sich überlegen, ob sich
/tmp als TMPFS für das System insgesamt rentiert oder
eher nicht. Ich persönlich ziehe es in solchen Fällen
vor, die betreffende Software -- wenn möglich -- so zu
konfigurieren, dass sie ihre Daten anderswo ablegt.
Dann ist man flexibler und kann auch später noch zu
einem TMPFS wechseln, ohne andere Software, die auch
/tmp verwenden will, zu beeinträchtigen.

Ich bin mal willkürlich ein paar Systeme durchgegangen,
auf die ich gerade Shells habe (einige verwenden TMPFS,
einige noch das klassische MFS):

Filesystem 1M-blocks Used Avail Capacity Mounted RAM(MB)
/dev/md0 989 0 910 0% /tmp 4096
tmpfs 10240 0 10239 0% /tmp 16384
/dev/md0 247 0 227 0% /tmp 512
/dev/md0 290 0 227 0% /tmp 1024
/dev/md0 290 1 265 0% /tmp 1024
tmpfs 512 0 511 0% /tmp 2048
tmpfs 512 0 511 0% /tmp 2048
tmpfs 400 1 398 0% /tmp 1024
/dev/md0 193 0 177 0% /tmp 256

Wie man sieht, liegt das nirgends nennenswert etwas auf
/tmp, zumindest nicht dauerhaft. Da ist TMPFS ein idealer
Kandidat.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"C is quirky, flawed, and an enormous success."
        -- Dennis M. Ritchie.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 02 Dec 2012 - 15:49:53 CET

search this site