Re: diskless system ohne swap

Am Do, den 29.04.2004 schrieb Bernd Walter um 21:01:
> 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.
[...]
> > 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.

Na gut. Aber es geht ja nicht exakt um die letzten drei Bytes, muß
reichen.

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

Danke, ist weg.

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

Nun ja, Netz nur zur Enwicklung und ggf. Wartung (wenn nicht serielle
Konsole). Wie klein dürfen die werden?

Loopback muß ja funktionsfähig bleiben, denke ich, aber:

zaphod# sysctl -a |grep space
...
net.local.stream.sendspace: 8192
net.local.stream.recvspace: 8192
net.local.dgram.recvspace: 4096
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 57344
net.inet.udp.recvspace: 42080
net.inet.raw.recvspace: 8192

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

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

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

Schnell gehen wird es nicht, aber das ist eines der Probleme, die ganz
oben auf meiner Liste stehen. Es sollte nicht so schwer sein, dem
XServer mit ein paar Zeilen C beizubringen, erstmal den Speicher
auszunullen ... ich dachte schon an dd oder ein kleines
selbstgestricktes, aber an den Speicher der Grafikkarte kommt man nicht
so einfach.

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

Damit werde ich mal rumspielen, obwohl in diesem Fall die Optik schon
eine gewisse Rolle spielt. Das Programm benutzt GTK+1.2 und sollte
eigentlich mit einer "Theme Engine" laufen, die aber wieder rausfliegt,
weil sie die Redraw-Steuerung an einer Stelle empfindlich stört.

Ich könnte mir eine 256 Farben Palette vorstellen, damit erreicht man
hübsche Metallic-Effekte. ;)

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

Jupp.

Vielen Dank erstmal,
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 30 Apr 2004 - 09:37:32 CEST