Re: diskless system ohne swap

Moin,

Ich antworte mal auf mehrere E-Mails zusammen. Dann müssen
die Leute, die's nicht interessiert, nur eine Mail wegklik-
ken und nicht vier. ;-)

Marc Santhoff <M.Santhoff(at)t-online.de> wrote:
> Am Do, den 29.04.2004 schrieb Oliver Fromme um 11:12:
> > Je nach Graphikkarte mappt der XFree86-Prozeß den Video-RAM
> > der Karte in sein Prozeßimage, manchmal sogar mehrfach mit
> > unterschiedlichen Alignments. Bei einer Karte mit 32 Mbyte
> > Video-RAM kann es durchaus passieren, daß diese Mappings
> > 128 Mbyte ausmachen. Dadurch kann der Prozeß in »ps« und
> > »top« sehr groß erscheinen, aber in Wirklichkeit belegt er
> > nicht annähernd soviel tatsächlichen RAM.
>
> Also meine Angaben stammen von top, da konnte ich zugucken, wie der
> Speicher gefressen wird, bis es knallt.

Das hatte dann wohl eine andere Ursache.

> Woher bekommt man denn zuverlässige bzw. realistische Werte?

Gar nicht. :-)

Prinzipiell vertraue ich der Ausgabe von »ps« mehr als der
von »top«. Aber beide zeigen natürlich immer nur einen
Teil der Realität an (u.U. sogar inkonsistente Daten, da
das System ja währenddessen nicht stehenbleibt), und das
Größte Problem ist vielleicht der Mensch vor dem Bild-
schirm, der die angezeigten Daten falsch interpretiert. ;-)

Die Memory-Mappings eines Prozesses kanst Du übrigens in
/proc/$PID/map nachschlagen (sofern das procfs gemountet
ist). Vielleicht war es ja eher das, worauf Deine Frage
abzielte.

> > Das Caching von Bitmaps sollte (wiederum je nach Karte und
> > deren Treiber) im Video-RAM der Graphikkarte erfolgen und
> > nicht unbedingt im Hauptspeicher.
>
> Nun ja, die Hardware in diesem Fall ist eine winzige (3,5" Format)
> Hauptplatine mit Geode 300 MHz und Onboard-Grafik - shared memory
> natürlich. Hoffentlich wird nicht nochmal parallel gemapped.

Ob das zusätzlich (vielleicht sogar mehrfach) parallel ge-
mappt wird, ist ja egal -- die Mappings kosten _keinen_
zusätzlichen RAM (außer minimal für die Page-Tables). Das
sind reine Virtual-Memory-Mappings.

> Jetzt nach der ganzen Aktion habe ich die Testdatenmenge reduziert und
> es sind aktuell (laut top) 93 MB von 128 MB frei und 10 MB Buffer.
> Allerdings direkt nach dem Start, die Werte schrumpfen noch ein bischen
> während des Betriebs.

Der von top angezeigte »freie« Speicher schrumpft sowieso
im Betrieb und nähert sich irgendwann mehr oder weniger
weit dem Wert 0. Das ist normal und erwünscht. Ungenutz-
ter Speicher ist vergeudeter Speicher -- normalerweise wird
er mindestens zum Cachen verwendet.

> Am Do, den 29.04.2004 schrieb Bernd Walter um 21:01:
> > MAXUSERS auf einen kleinen Wert setzen dürfte auch etliches bringen,
> > aber du musst natürlich darauf achten wann es zu klein wird.
> > Durch MAXUSERS werden etliche Limits gesetzt - unter anderem auch
> > die Größe von einigen statischen Tabellen des Kernels.
>
> Steht derzeit auf Null, bringt es was, mal mit kleinen Werten wie etwa 3
> zu spielen?

Probier's aus. Per Default (wenn auf 0), dann wird es an-
hand der RAM-Größe gesetzt, d.h. bei 128 Mbyte RAM hättest
Du effektiv maxusers=128, was für Deinen Anwendungsfall zu
hoch ist.

Probier mal maxusers=16. Das sollte ganz gut passen. Von
den Wert hängen z.B. die Default-Größen der Process-table,
File-table und Mbufs ab. Diese Größen kann man auch alle
separat einstellen, wenn nötig.

Die meisten Abhängigkeiten von maxusers kann man im Source
in src/sys/kern/subr_param.c nachlesen. Den Default für
die Mbufs findet man in src/sys/kern/uipc_mbuf.c:

#define NMBCLUSTERS (512 + maxusers * 16)

Im laufenden Betrieb teilt Dir z.B. »pstat -t« mit, wie
Dein File-table gerade belegt ist, und »netstat -m« infor-
miert Dich üebr die Mbufs. Die Anzahl der laufenden Pro-
zesse sagen »ps« und »top«, und die Größe des Process-
table sagt »kern.maxproc«.

In jedem Fall sollte die aktuellen Werte (unetr Last) bzw.
die Peak-Wert deutlich unter den maximalen Limits bleiben.

Wenn Du das alles im Hinterkopf hast, kannst Du maxusers
ziemlich optimal anpassen. Laß aber im Zweifelsfall lieber
etwas mehr Luft. Ein paar Bytes zu verschwenden ist bes-
ser, als die Gefahr in Kauf zu nehmen, daß das System an
die Kante läuft.

> > Wie der Oliver schon schrieb kann man z.B. bei SCSI die Meldungen aus
> > dem Kernel rauslassen.
>
> Hm, für umass an da0 brauche ich SCSI ja doch, wie macht man das?

Kannst Du in der Kernel-config meienr mp3-Box spicken:
http://www.secnetix.de/~olli/cantaro/kernel_config.txt

# SCSI peripherals
# These are included because they're required by certain
# USB umass storage devices.
device scbus # SCSI bus (required)
device da # Direct Access (disks)
options SCSI_NO_SENSE_STRINGS
options SCSI_NO_OP_STRINGS

> > Features vom X Server reduzieren bringt einem wenig im Vergleich zu
> > dem Speicher der durch die Clients belegt wird - reduzieren sollte
> > man natürlich denoch.
>
> Wirklich sparen kann man, wenn sich möglichst viele Programme die
> gleichen Ressourcen teilen, also möglichst nur KDE- oder
> Gnome(GTK)-Programme,

Möglichst _weder_ KDE _noch_ Gnome. Das sind ja beides
ziemliche Resourcenfresser.

> statt 50 Fonts gleichzeitig nur 3-4 (mehr haut
> sowieso ins Auge).

Wie wahr, wie wahr ...

> Am Do, den 29.04.2004 schrieb Oliver Fromme um 10:56:
> > Eine Alternative wäre noch, über NFS zu swappen. Das ist
> > durchaus nicht so schlecht, wie es klingen mag, denn mit
> > halbwegs guter Hardware ist das Netz kein nennenswerter
> > Engpaß. Die Latenz der Platte auf dem NFS-Server ist mei-
> > stens entscheidender.
>
> Kein NFS, kein Netz im Normalbetrieb. (FreeBSD ohne Netz, fast ein
> Eunuch ;)

Prima, dann kannst Du ja theoretisch INET, ether und den
ganzen krempel weglassen. Das sollte enorm Platz sparen.
Allerdings geht dann auch loopback und einiges andere
nicht mehr. Hmm. Vermutlich geht X dann nicht mehr.
Also vergiß es wieder. :-)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
Perl is worse than Python because people wanted it worse.
        -- Larry Wall
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message