Bitte um kleine Beratung zu RAM

FreeBSD belegt einfach allen Speicher. Wenn dein System lange genug Up ist, ist irgendwann der RAM voll und das System geht in den SWAP.

Das ist ein immer wieder verbreitetes Mißverständnis, weil es bei Linux m.o.w. so funktioniert.

Abhängig davon, wie die VM (Memory Verwaltung im Kernel) konstruiert ist, gibt es zwei Arten Swapspace bzw. Paging:
1. der Swap vergrößert die Memory, wird gleichsam hinten an den RAM drangepappt sodass man insgesamt mehr (aber halt sehr langsamen) Speicher hat. ZB Linux.
2. der Swap "covert" die Memory, ist sozusagen ein vergrößerter Spiegel. Jede Seite im RAM hat von vorneherein ihren Platz im Paging, wo sie ggfs. hinkopiert wird. ZB AIX bis Rel. 5 (das läuft gar nicht an, wenn der Swap nicht mindestens so groß ist wie der RAM)

FreeBSD gehört wie alle BSD zu 2, sollte also eigentlich ohne Swap gar nicht laufen.
Allerdings gab es Überlegungen, wie man das verbessern kann, sodass es nun eben doch auch ohne Swap einigermaßen läuft. U.a. hier erklärt: /usr/share/doc/papers/newvm.*

Dennoch wollen die BSDs vom Design her eigentlich einen Swap haben und schieben da auch immer mal ein bischen was drauf. Es ist ja sinnvoller, einen Prozess, der beim Boot gelaufen ist und erst wieder beim Shutdown gebraucht wird, zwischenzeitlich auf den Swap zu schieben und derweil den dadurch freigewordenen Speicher zB als File-Cache zu nutzen.
 
Virtuelle Speicherverwaltung auf aktuellen Systemen ist im Grunde überall gleich, vollkommen unabhängig ob Windows, Linux, *BSD oder macOS. Das kann sich das OS nicht großartig aussuchen, da das alles von der Hardware vorgegeben und auch über die MMU in der CPU berechnet wird. Keines der Systeme braucht zwingend einen Swap-Space.

Linux hat hier den swappiness Parameter, um zu kontrollieren ab wann der Swap-Space genutzt wird. Setzt man den auf 0, dann wird der Swap-Space nur genutzt, wenn eine OOM Situation vorliegt. FreeBSD hat soweit ich weiß keinen entsprechenden Parameter.

Ansonsten: https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#idp60777376

FreeBSD uses a lot of swap space even when the computer has free memory left. Why?

FreeBSD will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. This heavy use of swap is balanced by using the extra free memory for caching.
Note that while FreeBSD is proactive in this regard, it does not arbitrarily decide to swap pages when the system is truly idle. Thus, the system will not be all paged out after leaving it idle overnight.
 
Linux hat hier den swappiness Parameter, um zu kontrollieren ab wann der Swap-Space genutzt wird. Setzt man den auf 0, dann wird der Swap-Space nur genutzt, wenn eine OOM Situation vorliegt. FreeBSD hat soweit ich weiß keinen entsprechenden Parameter.

Nein, aber einen gegenteiligen, der bewirkt, dass so früh wie möglich gepaged wird:

vm.swap_idle_enabled=1
 
Ein ganz bedeutender Unterschied zwischen FreeBSD uns Linux ist inzwischen auch Overcommit. FreeBSD betreibt seit 10.0 oder 11.0, weiß ich nicht mehr genau, in der Standardinstallation kein Memory Overcommit mehr. Wenn eine Speicheranforderung mehr Speicher belegen würde, als verfügbar ist, schlägt sie fehl. Die meisten Linux-Distros hingegen haben in der Standardeinstellung unbegrenztes Overcommit eingeschaltet, Speicheranforderungen schlagen niemals fehlt. Wird der zugeteilte Speicher zu einem späteren Zeitpunkt wirklich genutzt, dass System kann ihn dann aber nicht bereit stellten, schaut der OOM-Killer vorbei.

Das ist vor allem in Extremsituationen interessant. Zum Beispiel ist der ZFS ARC ein recht träger Cache-Mechanismus. Er kann Speicher freigeben, aber nicht sofort, es dauert ein paar Millisekunden bis sogar Sekunden. Wenn nun plötzlich eine große Speicheranforderung kommt - weil eine VM startet, weil ein großes Bild in Gimp geöffnet wird, etc. - kann das System die Speicheranforderung nicht erfüllen, sie schlägt daraufhin fehl. Mit ausreichend Swap hat das System aber genügend Luft um den Engpass überbrücken zu können.
 
  • Like
Reaktionen: PMc
Versteht mich bitte nicht falsch: ich verstehe diese Dinge eh nicht richtig und will deshalb auch keinesfalls eine Empfehlung abgeben, wie man denn in Zukunft glücklich leben kann und nie mehr SWAP benutzen muss.
Wir hatten die Diskussionen ja schon häufiger.
Ich nutze seit vielen Jahren SWAP nur widerwillig und zwar auf allen Rechnern. Und deshalb habe ich für mich persönlich damit Erfahrung gemacht und die sagt: ich brauche keinen SWAP. Es hat bei mir nicht ein einziges Mal einen Fehler gegeben, wenn ich Systeme ohne SWAP benutzt habe, auch nicht mit FreeBSD.
Trotzdem habe ich aktuell wieder einen SWAP aktiv, trotz meiner Überzeugung und persönlichen Erfahrungen und trotz ausreichend RAM. Generell ist das nicht störend, FreeBSD verbraucht zwar allen RAM, aber es greift nicht laufend auf den SWAP zu. Manchmal aber doch, logischerweise. Wenn nun genau die Platte mit dem SWAP zB ausgerechnet einen Fehler hat oder das SWAP-Device sonst wie sehr lahm ist oder man eben einen Verdacht in der Richtung hat oder was auch immer da eine Rolle spielen könnte, dass man mit seinem SWAP im Argen liegt, dann kann man den einfach mal abschalten. Es gibt ja swapoff [SWAPON(8)]. Man braucht nicht sein System neu aufzusetzen. Das kann man ganz einfach mal probieren, jeder (also root), jederzeit.
Was ich auch getestet habe, ist einen Bereich im RAM für SWAP zu nehmen.
Auch das hatten wir schon mal diskutiert und es ist nicht mehr, als eine meiner typischen Trotzreaktionen. Trotz besseren Rats von kompetenten Leuten, will ich das einfach manchmal wissen und wenn ich ein System mit 16GB RAM rund und zufrieden laufen lassen kann und dann plötzlich 32G habe, warum sollte das nun schlechter laufen, wenn ich ihm 2G des RAMs abzweige und das für SWAP nutze? Natürlich ohne jeden Sinn, ich meine SWAP im RAM: das ist ja schon beinahe pervers (darf man so etwas heute noch sagen?).

Andererseits ist es in meinen Augen genauso pervers, wenn ein Betriebssystem heute noch immer blind einen SWAP verlangt. Und zwar nicht für die verschiedenen anderen Möglichkeiten, wofür SWAP gebraucht werden kann, wie etwa crash-dumps oder zur Hibernation, sondern als wesentlichen Bestandteil zur ordnungsgemäßen Funktion. Was soll das denn? Wieso brauche ich auf dem besagten 16GB-RAM System einen SWAP? Eigentlich gar nicht. Dann baue ich auf 32GB aus und brauche immer noch einen SWAP? Und dann auf 64GB-RAM, aber immer noch soll ich einen SWAP benutzen, weil das System sonst im ungünstigsten Fall mal kollabieren könnte?

Diese Diskussionen habe ich begonnen, ich glaube, schon bevor ich zum ersten mal FreeBSD benutzt habe und natürlich bin ich ein unverbesserlicher Sturkopf und habe auch wirklich keine detaillierten Kenntnisse zur Funktion von Betriebssystemen, weshalb ich eben auch den Rat der kompetenten Leute hier annehme.
Aber die Entwickler der Betriebssysteme scheinen mir ebenfalls stur zu sein und nicht gerne neu nachzudenken. Das Konzept mit zwingend verlangter SWAP scheint mir nicht mehr zeitgemäß und das schon seit mehr als einem Jahrzehnt. Hier könnte eine gewisse Dynamik einfließen und erkennen, ob ein SWAP wirklich Sinn macht oder eben auch eingespart werden kann.

Dann wäre ich vielleicht deutlich glücklicher.
Aber alle anderen sind es heute auch schon, also glücklich mit SWAP in jedem Fall und insofern, sollten wir das hier auch beenden, bevor es mal wieder OT wird und nur, weil ich eben stur bin, nicht, weil ich kompetent bin.
 
Dann verlasse doch das Reich der Mythen und Legenden und informiere dich wie ein Computer und virtuelle Speicherverwaltung funktioniert. Das ist alles ziemlich pragmatischer Kram und braucht auch keine größeren Kenntnisse in Mathematik und/oder Logik.

Ansonsten, wenn dich das pure Vorhandensein von Swap-Space so unglücklich macht, dann mach's halt aus.

Es gibt auch Leute, die stellen sich Geräte in den Raum, die angeblich Luftmoleküle umsortieren, damit der Klang von Musik besser ist und sie schwören darauf, dass das auch der Fall ist. Andere kaufen sich für mehrere tausend EUR Kabel, damit es einen ähnlichen Effekt hat. Dass das alles ziemlicher Quatsch ist kann dir jede informierte Person sagen. Aber wenn die Person damit besser lebt und auch niemanden schadet... ¯\_(ツ)_/¯

Man muss sich halt nur auf Konter gefasst machen, falls man anfängt irgendwelchen Unsinn zu verbreiten.
 
Ach, waren das noch zeiten, als die Leute sich noch nicht mehr Speicher leisten konnten als sie unbedingt brauchten, und dann froh um den Swap waren...
 
Ach, waren das noch zeiten, als die Leute sich noch nicht mehr Speicher leisten konnten als sie unbedingt brauchten, und dann froh um den Swap waren...
Das ist wohl wahr und alles war sauteuer. Ich hab noch eine über 30 Jahre alte schöne Preisliste für Hard- und Software. Da wird einem aber schwindlig ....
 
Können wir das Offtopic Geplauder bitte sein lassen? Danke!
Klar, allerdings ist es für mich kein Plaudern, wenn jemand Allgemeinplätze unterstellt (früher war alles besser) die hier von niemandem geäußert wurden. Und wenn das in einem Thread passiert, den ich begonnen habe, und mich das stört, dann sage ich das.
 
Klar, allerdings ist es für mich kein Plaudern, wenn jemand Allgemeinplätze unterstellt (früher war alles besser) die hier von niemandem geäußert wurden. Und wenn das in einem Thread passiert, den ich begonnen habe, und mich das stört, dann sage ich das.

Also die letzten 3 Posts über meinem offtopic Beschäftigten sich mit der "guten alten Zeit". Und das mein Posting nicht wörtlich zu nehmen ist sollte eigentlich klar sein.
 
Früher hat man auch wegen der hohen RAM-Preise deutlich Resourcen freundlicher programmiert...

Man hat früher einen PC nicht deshalb mit wenig RAM ausgestattet, weil es „teuer“ war sondern weil damalige CPUs, Boards, Chipsätze, Bus etc die maximale RAM Ausstattung beschränkten - so wie das heute auch noch ist!

Was die Programmierung betrifft, so kommt es ja immer darauf an was und wofür programmiert wird.
Auch heute werden noch in Assembler, C oder sogar in Forth extrem ram-sparend die 8Bit, 16Bit oder 32Bit Mikrocontroller mit nur wenigen kB RAM programmiert - oftmals bar-metal , was heißt dass das Betriebssystem gleich mit programmiert werden muss ... was komplizierter klingt als es ist ... denn das simpelste Betriebssystem ist erstmal nur ein for( ; ; ) { /* anwendungsprogramm */ } - also eine Endlosschleife die der bootloader startet.
Und bei diesen kommt es oft auf jedes Byte an - da überlegt man sich ganz genau, welche Variablen man nimmt - wie groß der Stack wird und wann man welchen Speicherbereich alloziert!

Durch die seit ca. 20 Jahren an den Hochschulen zu beobachtende Heiligsprechung der objektorientierten Programmierung wird natürlich unglaublicher Ballast in heutige Software gebunden - aber das ist ein ganz anderes Thema ;-)
 
Das hat nicht sonderlich was mit Objektorientierung zu tun. 30-50%iger Anstieg am RAM-Verbrauch kommt alleine schon durch die Verwendung von 64bit Binaries. Dann sind z.B. die heutigen Dateisysteme nicht einfach nur mehr eine simple Zuordnungstabelle, sondern haben allerhand Schutz- und Performancesysteme eingebaut. Weiterhin kompilieren wir noch allerhand Schutzmaßnahmen in so ziemlich alle Binaries mit rein (Stack-Protector usw.). Wir übertragen Daten in der Regel auch nicht mehr unverschlüsselt, also brauchen wir noch einen Entschlüsselungs-Schritt. Unser Zeichensatz, mit dem wir uns hier unterhalten ist auch nicht mehr einfach nur 7bit US-ASCII sondern in der Regel UTF-8. Bilder und Videos sind nicht mehr 320x200 Pixel oder weniger groß, sondern wir schauen uns 1080p, 1440p, 2160p Videos und Bilder an... bei Audio sieht es nicht anderes aus... und das sind auch nur einige Beispiele von vielen weiteren.
 
... Unser Zeichensatz, mit dem wir uns hier unterhalten ist auch nicht mehr einfach nur 7bit US-ASCII sondern in der Regel UTF-8 ...

Egal ob wir nun ein C Programm für einen 8 Bit AVR oder unter 64Bit FreeBSD entwickeln ...
egal ob auf einer Plattform der Datentyp ‚char‘ nun signed oder unsigned ist - welchen Speichermehrverbrauch erwartest Du bei UTF-8 im Gegensatz zu 7 Bit ASCII ?
 
welchen Speichermehrverbrauch erwartest Du bei UTF-8 im Gegensatz zu 7 Bit ASCII ?

Die dazugehörigen Libraries wie ICU, um Unicode überhaupt grob "beherrschen" zu können. Und wie ich schon sagte, es gibt noch wesentlich mehr Beispiele. UTF-16 ist auch ein Ding und allgemein wesentlich mehr Encodings als nur US ASCII. char16_t und char32_t sind auch ein Ding und werden bei Unicode Behandlung normalerweise genommen und nicht nur "char".

Man kann das RAM Problem auch ganz simpel zusammenfassen: Wir haben heutzutage einfach wesentlich mehr Daten, die verarbeitet werden müssen. Ob da ein Programm nun in Assembler, C, C++, Fortran, Rust, Go oder sonst was implementiert ist, ist da recht nebensächlich.
 
Also die letzten 3 Posts über meinem offtopic Beschäftigten sich mit der "guten alten Zeit". Und das mein Posting nicht wörtlich zu nehmen ist sollte eigentlich klar sein.
Okay, es war wohl doch witzig gemeint, aber mich würde vielmehr interessieren, ob Du den Kommentaren zustimmen kannst, oder nicht :)

@Vril ist was den Kommentar von @juedan betrifft anderer Meinung und bringt da auch Details. Beim Reden über ein gewisses init-System gehörtest Du doch auch zu denjenigen, die Details zugunsten dieses Systems gebracht haben (und meine Kontrahaltung wurde dadurch z. B. deutlich abgemildert).

Darum geht es mir, ich möchte doch nicht streiten.

Heute kaufe ich mir übrigens den RAM und werde berichten.

Viele Grüße
Holger
 
Darum geht es mir, ich möchte doch nicht streiten.
Hallo Holger,
Du wirst mir jetzt doch nicht harmoniesüchtig?;) Eine sachliche Streitkultur ist notwendig, wenn ich mich der "Wahrheit" nähern möchte. Eine Konfliktvermeidungsstrategie mag zwar diplomatisch in einigen Fällen durchaus praktikabel sein, aber zielführend ist sie nie. Erkenntnisgewinn bekomme ich nicht durch Vermeidung von Auseinandersetzungen, vorausgesetzt sie sind sachlich begründet, bleiben fair und werden nicht persönlich. Dann aber sind sie durchaus fruchtbar.:)

Grüße

Ralph
 
Okay, es war wohl doch witzig gemeint, aber mich würde vielmehr interessieren, ob Du den Kommentaren zustimmen kannst, oder nicht :)

Naja natürlich war früher RAM und Speicher teurer, ist für das hier und jetzt aber irrelevant. Heute wird einem das alles hinterher geworfen, also wäre es blöd das ganze nicht zu nutzen.
Anwendungsbeispiele hat NUKE schon genannt, ich würde vielleicht auch noch hinzufügen, dass die Software ansich deutlich billiger wird.
Als Entwickler muss man sich nicht um RAM oder auch Performance großartig kümmern*, diese Probleme können mit HW erschlagen werden. Dafür kann sich auf Portabilität, Testbarkeit und Lesbarkeit konzentrieren. Für z.b. 100 Mannstunden bei einer Softwarefirma bekommt man heute deutlich mehr als vor 20 Jahren.


*Natürlich gibts auch weiterhin Gebiete in denen das wichtig ist, aber eben nicht in der breiten Masse der Softwareentwicklung.


Zum RAM - Swap Thema: Es wurde hier und auch in anderen Threads schon alles gesagt, die Frage kommt ja alle halbe Jahre wieder auf. Wer meint es besser zu wissen als die Entwickler von diversen Betriebssystemen macht halt ohne Swap.

Prinzipiell ist es auch einfach zu testen: Monitoring aufsetzen z.b. Munin. Dann kann man notieren, wenn der Rechner "gefühlt" langsam ist und später mit Swapin vergleichen.
Der Performancegewinn von zusätzlichem Pagecache den man durch Swap bekommt ist schwieriger zu messen, aber hat man ZFS könnte man z.b. die ARC Cache Hitratio vergleichen.
 
Naja natürlich war früher RAM und Speicher teurer, ist für das hier und jetzt aber irrelevant. Heute wird einem das alles hinterher geworfen, also wäre es blöd das ganze nicht zu nutzen.

Man muss sich die Relation vor Augen führen: über den Daumen gepeilt kostet aktuell 1 Stunde Entwicklerzeit soviel wie 16 GB RAM.
 
Zurück
Oben