Re: diskless system ohne swap

Hups, hätte ich doch glatt vergessen, hier nochmal was dazu zu schreiben
...

Am Mo, den 03.05.2004 schrieb Oliver Fromme um 12:35:
[...]
> > 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. ;-)

Nun ja, die ungefähren Werte tun's ja auch zur Orientierung.

> 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 kann schon sein. :)

War ich mal wieder zu blind oder gibt es darüber keine Dokumentation?

> > > 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.

Ja, ist mir auch aufgefallen, als ich mich wider beruhigt hatte. Wäre ja
auch sinnlos, wenn dabei noch brauchbarer Speicher verdeckt wird, der
Adressraum ist schließlich groß genug ...

[...]
> > 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.

Also die Systemvariable (kern.maxusers oder so) stand bei dem Hobel auf
32, wenn der kernel mit 0 übersetzt war. Wie gesagt mit 128 MB RAM.

> 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.

Jupp, sowas suchte ich u.a. Ich bin im Moment bei bei 12 geblieben und
beobachte noch, aber nachdem ich die Vergeßlichkeiten aus dem Programm
entfernt habe, geht's auch, der Speicher reicht.

Und zwei zusätzliche vterms zum login reichen dicke. Später
wahrscheinlich sogar keins, wenn alles nach Wunsch funktioniert.

[...]
>
> > > 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

Ah ja, geschehen, Danke.

> > > 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.

Ich meinte das eher bezogen auf Arbeitsplätze, wo es nötig ist
grafisches Geraffel zu benutzen. Dann sollte man lieber zusehen, nur
Gnome oder nur KDE-Programme zu benutzen, um möglichst nicht noch Qt,
XForms und was sonst noch für Bibliotheken nachgeladen zu bekommen.

In der Praxis ist das aber meist nicht durchzuhalten ...

[...]
> > 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. :-)

Wenn ich Langeweile bekommen sollte, könnte es sein. ;)

Aber im Ernst, ich brauche zur Diagnose schon ein Netzwerk und die
serielle Konsole. Da würde ich schon eher eine FAQ aus den gessammelten
Informationen machen.

> Gruß
> Olli

Ebenfalls, und vielen Dank für die wirklich erhellenden Infos,
Marc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 14 May 2004 - 09:37:53 CEST