Re: diskless system ohne swap

On Thu, Apr 29, 2004 at 08:27:57PM +0200, Marc Santhoff wrote:
> Am Do, den 29.04.2004 schrieb Oliver Fromme um 11:12:
> > Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> > > [...]
> > > 128M ist aber auch nicht so sehr viel für X.
> >
> > Sollte aber eigentlich genügen.
> >
> > > Mein XFree86 Prozess belegt z.B. 217M - und da ist der OS Bedarf
> > > noch nicht mit drin.
> >
> > 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. Woher bekommt man denn
> zuverlässige bzw. realistische Werte?

Strengenommen gar nicht.
top liefert nicht den belegten Speicher, sondern den belegten
Adressraum und den Anteil dessen, der direkt zugreifbar ist.
mmap Hardware Speicher wird genauso hinzugezählt, wie shared memory.
shared memory ist zwar genauso Speicher, aber kann von anderen
Prozessen mitbenutzt werden, was dann wiederum in der Summer weniger
ausmacht als das was durch simple Addition aller Prozesse rauskommt.
Weiterhin ist der Programmcode in der Regel ein mmaped file, was dann
auch ohne swap jederzeit aus dem RAM geworfen werden kann, da es ja
bereits auf einem anderweitigen Speichermedium liegt.

Auch die freien Werte muss man dementsprechend bewerten, da der
belegte Platz durchaus wiederverwertbar sein könnte.
Insbesonders der Cache Bereich ist quasi ebenfalls frei, da dessen
Inhalt jederzeit verworfen werden kann.

Es gibt auch jede Menge andere Speicherfresser auf die du evtl
verzichten kannst.
UFS_DIRHASH ist eines davon.

net.inet.tcp.sendspace und net.inet.tcp.recvspace kannst du
vermutlich ebenfalls deutlich kleiner setzen solange du nicht
viel TCP Bandbreite auf Strecken mit hoher Laufzeit brauchst.

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.

Wie der Oliver schon schrieb kann man z.B. bei SCSI die Meldungen aus
dem Kernel rauslassen.

usw...

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

Wenn doch spielt es keine Rolle, da die Hardware das sauber kann.
Du kannst mal mit der Einstellung zur shared Größe spielen, aber
grundsätzlich ist das Problem anders zu lösen.

> Wobei das auch solche Sache ist, der VESA-XServer schafft es nicht, den
> Speicher als erstes zu löschen sondern macht ein quietschbunten Schirm
> oder zeigt Artefakte vom letzten Programmbild. Dafür suche ich noch nach
> einer Lösung ...

Das sehe ich mit meinem Notebook auch.

> > > > -Andreas,
> > > > ... der meint, dass ein X-Terminal mit 128 MB auskommen muesste
> >
> > Das meine ich auch -- mit der richtigen Graphikkarte.
> >
> > Meiner hier belegt aktuell ca. 40 Mbyte. Das ist mit einer
> > Matrox MGA G400 (AGP) Mit XFree86 4.2.0 bei 1440 × 1080 Pi-
> > xeln in Truecolor, wobei ein Browser geöffnet ist (Opera),
> > Acrobat-Reader, und ca. 20 Terminal-Fenster (12 jterms und
> > ein paar xterms). Meine typische Arbeitsumgebung halt.
>
> Die ganze Sache ist ja auch noch im Wachstum, z. Zt. geht ein Teil des
> Hauptspeichers für die Garfik weg (weiß garnicht, wieviel) und 8 MB für
> /var (stand noch auf default).

Die Reduktion der Farbtiefe von Bitmaps ist eine lohnende Geschichte.
Wenn du also selbstgeschriebene X11 Applikationen laufen hast, die
Icons usw benutzen evtl mal einen Gedanken wert.
Oftmals reichen ja 16 Farben aus.

> 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.
>
> Damit kann ich leben, vor allem wo im Programm selbst noch
> Optimierungsspielraum schlummert.

Ja - das sieht schon recht gesund aus.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message