Und deshalb sollte man auch mit 8GB RAM nicht auf SWAP verzichten

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
Code: 
last pid: 60282;  load averages:  1.57,  1.15,  1.06                 up 6+12:33:14  07:49:59
112 processes: 4 running, 107 sleeping, 1 waiting
CPU 0: 47.5% user,  5.1% nice,  2.4% system,  0.0% interrupt, 45.1% idle
CPU 1: 52.5% user,  3.1% nice,  5.9% system,  0.0% interrupt, 38.4% idle
Mem: 5073M Active, 1026M Inact, 1535M Wired, 251M Cache, 827M Buf, 12M Free
Swap: 8192M Total, 1590M Used, 6602M Free, 19% Inuse

Edit: SWAP Usage steigt übrigens Munter weiter, wobei keine wahrnehmbaren Performanceeinbrüche zu beobachten sind. Das leppert sich halt so zusammen bei ein paar Tagen Uptime.
 
Zuletzt bearbeitet:
Tjoa, FreeBSD ist halt sehr aggressiv darin länger nicht gelaufene Prozesse auszuswappen, um den RAM für andere Dinge frei zu bekommen. Und sei es nur für Dateisystempuffer. Dadurch, dass 1590MB in der Swap statt im RAM liegen, dürfte das System insgesamt sogar leicht an Geschwindigkeit gewinnen. Und wenn man tatsächlich mal in Speichernot geraten sollte - das kann schneller passieren, als einem lieb ist - wird man seine Swap sowieso lieben lernen.
 
Das war jetzt kein präventives Swappen. Der Speicher wurde schlicht gebraucht. Kurz gesagt ohne SWAP wäre das System abgeraucht. Zumindest wären ein paar große Prozesse wie Firefox und Xorg gestorben. Der SWAP gebrauch ging noch auf 3g hoch.

Schuld ist natürlich mein Einsatz von tmpfs. Etwas wovon man meiner Meinung nach die Finger lassen sollte, wenn man auf SWAP verzichtet.

Edit: Ich stelle mir gerade vor ich würde noch i386 fahren. Da schüttelt's mich, das reicht ja nicht mal mehr für ein modernes Telefon. Ist schon bizarr. Auf meinen 8051 komme ich komfortabel mit weniger als 4kb RAM aus.
 
Kamikaze schrieb:
Schuld ist natürlich mein Einsatz von tmpfs.
Zum Vergrößern anklicken....

Bei mir auch ab und zu. KDE4 und Browser, der auf tmpfs cached, dann noch munter compilen, LibreOffice etwa. Da kann es schon ab und zu ein bisschen swapen. Wenn ich mich richtig erinnere, waren es bei mir auch etwa so um die 1,5 GB ausgeswapt beim letzten LibreOffice Build.
 
Auf meinem Linux-Laptop mit 16 GB Ram, habe ich alleine dafür Swap, dass ich suspend-to-disk nutzen kann.
 
16g gehen in meine alte Kiste gar nicht rein. 8gb ist das Maximum. Ausgeliefert wurde der Laptop seinerzeit mit 2GB … irgendwie erschütternd. Aber wie wir ja alle wissen. Man hat nie zu viel RAM.
 
Ich habe 16GB RAM in meinem Desktop und zusätzlich 8GB Swap da ich häufiger den RAM ausnutze. Ich würde aber auch jedem empfehlen wenigstens 2GB Swap anzulegen sicher ist nunmal sicher :)
 
Also 2G Swap halte ich fuer ein wenig zu wenig als Empfehlung fuer 16G Ram.
Ich nehm auch immer vorsichthalber die Haelfte: 16G Swap xD
 
lockdoc schrieb:
Also 2G Swap halte ich fuer ein wenig zu wenig als Empfehlung fuer 16G Ram.
Ich nehm auch immer vorsichthalber die Haelfte: 16G Swap xD
Zum Vergrößern anklicken....

2GB war mehr so ne Einsteiger größe also selbst bei 1GB oder kleiner würde ich das erstmal so empfehlen. Bei meinem nächsten RAM Upgrade würde mein Swap auf 8GB bleiben, da ich keine Lust auf Partitions gefrickel habe.
Du hast eindeutig den Größeren, ICH WILL AUCH SOVIEL HABEN ;'( :D
 
laemodost schrieb:
Doch, 640kb sind mehr als genug für jeden. ;)
Zum Vergrößern anklicken....
Auf meinen 8051 wären schon 64k üppig. Mehr kann ich sowieso nicht addressieren. Na ja, das ist jetzt nicht ganz wahr, ich könnte, entsprechende Performance Einbußen hinnehmend, mit 20 Bit addressieren und so 1m externen RAM anbinden. Aber bisher bin ich mit 3k ja immer ganz gut ausgekommen.

Was SWAP Größen angeht, ich bin zwar nicht so Konservativ, dass ich die 2-3 mal RAM Regel befolge. Aber weniger SWAP als RAM mache ich auch nicht.
 
Wenn du nach einem crash einen kompletten memory dump ziehen willst, brauchst du auch min. so viel Swap wie RAM eingebaut ist.

Die dicksten Kisten, die ich habe, haben 512 GB und das wird manchmal schon eng, je nach Anwendung.
 
auch wenn das nach angeberei klingt... ich persoenlich krieg (als einzelanwender) locker mal 16gig voll. und das sind noch nichtmal meine selbstgestrickten proggies. mein freebsd numbercruncher hat 24gig. das ist auch der grund warum ich von openbsd abgerueckt bin: da ging das schlichtweg nicht sauber.

ist halt immer eine frage was man mit seiner hardware macht.
 
Ich wollte eigentlich bei mir auch mal nachrüsten jetzt, aber die RAM-Preise sind in den letzten Monaten doch wieder angezogen. Festplatten werden auch teurer, es scheint mit dem großen Fortschritt zu Ende zu gehen :|
 
dettus schrieb:
auch wenn das nach angeberei klingt... ich persoenlich krieg (als einzelanwender) locker mal 16gig voll. und das sind noch nichtmal meine selbstgestrickten proggies. mein freebsd numbercruncher hat 24gig. das ist auch der grund warum ich von openbsd abgerueckt bin: da ging das schlichtweg nicht sauber.

ist halt immer eine frage was man mit seiner hardware macht.
Zum Vergrößern anklicken....

Aus Interesse: Was heißt "in OpenBSD ging das nicht sauber"? Hab auf Anhieb auch nichts gefunden zu OpenBSD Maschinen mit "viel" RAM.
Im übrigen finde ich 24GB auch in Privatrechnern nicht mehr überraschend. Es ist vermutlich meistens übertrieben viel, aber eben auch nicht überraschend. Die Preise dafür sind einfach verdammt niedrig.
 
ich glaube bei 4.8 hatte ich keine lust gehabt mehr zu warten.
da musste ich immer wieder von hand bigmem=1 im sourcecode sagen.

und da hab ich einfach lust gekriegt mal was neues zu probieren.
 
Wenn Ihr alle so eifrig tmpfs nutzt, dann wäre es doch eine gute Idee, sich mit Hilfe von unionfs eine hybride Lösung zu basteln, so daß zumindest ein Teil der Dateien (z. B. die größeren) auf der Festplatte bleibt.
Gibt es da nichts Adäquates?
 
Wie wäre es damit statt solcher hässlichen Kludges einfach schnelleren Speicher anzuschließen, wenn man ihn braucht? Reicht hier jemand der Durchsatz (IOPS oder MiB/s) oder die Latenz einer SSD auf dem privaten Desktop/Laptop nicht zum Auskommen? Mir ist es zu lästig mir permanent Gedanken drum zu machen ob ich jetzt "große" Dateien habe oder nicht.
 
Tronar schrieb:
Wenn Ihr alle so eifrig tmpfs nutzt, dann wäre es doch eine gute Idee, sich mit Hilfe von unionfs eine hybride Lösung zu basteln, so daß zumindest ein Teil der Dateien (z. B. die größeren) auf der Festplatte bleibt.
Gibt es da nichts Adäquates?
Zum Vergrößern anklicken....
Wozu? Wenn es notwendig ist landen die Daten ja einfach über den Swap auf der Platte. Gehört zu den Dingen die halt einfach funktionieren.
 
edlomprul schrieb:
Aus Interesse: Was heißt "in OpenBSD ging das nicht sauber"? Hab auf Anhieb auch nichts gefunden zu OpenBSD Maschinen mit "viel" RAM.
Im übrigen finde ich 24GB auch in Privatrechnern nicht mehr überraschend. Es ist vermutlich meistens übertrieben viel, aber eben auch nicht überraschend. Die Preise dafür sind einfach verdammt niedrig.
Zum Vergrößern anklicken....

Das ist Schnee von gestern. OpenBSD unterstuetzt bigmem schon seit einiger Zeit problemlos, siehe:

http://www.undeadly.org/cgi?action=article&sid=20110413140750
 
:-) Stimmt auch wieder!
Es wäre halt eine umfassendere Lösung, nicht nur für temporäre Verzeichnisse. Man könnte so etwas für den ganzen /usr/ports-Zweig einrichten, so daß die vielen work-Unterverzeichnisse während des Port-Bauens im Speicher bleiben, aber das, was schließlich nach dem Cleanup übrigbleibt, doch noch auf der Platte landet. Auch für Flash-Speicher, deren Lebensdauer von der Zahl der Schreibzugriffe abhängt, wäre das nützlich.
Nötig wäre dazu ein unionfs mit tmpfs als Oberschicht und zwei zusätzlichen Features:
1. Eine Möglichkeit, bestimmte zu schreibende Dateien doch in die Unterschicht durchzureichen. Das geht momentan AFAIK nicht mit unionfs, man müßte sehr umständlich drum herumfrickeln.
2. Den Final backup beim umount des unionfs in die Unterschicht hinunter. Das ist ein Kinderspiel, ein winziges Skript.

Punkt 1 reduziert dabei halt den Speicherverbrauch und macht das Ganze nichttrivial. Ohne Punkt 1 wurde so etwas schon hie und da von Linux-Leuten vorgestellt.
 
Tronar schrieb:
:-) Stimmt auch wieder!
Es wäre halt eine umfassendere Lösung, nicht nur für temporäre Verzeichnisse. Man könnte so etwas für den ganzen /usr/ports-Zweig einrichten, so daß die vielen work-Unterverzeichnisse während des Port-Bauens im Speicher bleiben, aber das, was schließlich nach dem Cleanup übrigbleibt, doch noch auf der Platte landet. Auch für Flash-Speicher, deren Lebensdauer von der Zahl der Schreibzugriffe abhängt, wäre das nützlich.
Zum Vergrößern anklicken....
fstab schrieb:
tmpfs /tmp tmpfs rw 0 0
Zum Vergrößern anklicken....
make.conf schrieb:
WRKDIRPREFIX=/tmp/
Zum Vergrößern anklicken....
macht genau das was du beschreibst bei mir problemlos, ohne union und Gefrickel. Und das Bauen geht auch schneller.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben