Ubuntu/Scientific Linux in Virtualbox - RAM läuft voll

[Müs Lee]

Ahoi,

ich habe hier zwei VM mit Ubuntu und Scientific Linux, in denen OpenFOAM und OpenFOAM Extend laufen. Wenn ich eine Simulation laufen lasse, läuft kontinuierlich der RAM voll, bis ich entweder die VM neustarte oder das Limit erreicht wird, und zwar bei beiden. Ich glaube, dass es unabhängig davon ist, ob ich die jeweils letzten Ergebnisse der Simulation laufend lösche oder alle speichere, jedenfalls ist mir noch nichts Gegenteiliges aufgefallen. Wenn ich die VM ohne Simulation im Idle laufen lasse, tut sich nichts. Virtualbox ist Version 5.1.12, Host ist Windows 7 mit 32GB, die VM kriegt 24GB. Das gleiche passiert auch auf meinem Laptop mit ebenfalls W7 und 16GB RAM, davon 12 für die VM. Hat jemand eine Idee, woran das liegen könnte? Anscheinend werden die Ergebnisse laufend in den RAM geschrieben, aber der Platz wird nicht mehr freigemacht.

 

[honky-tonk]

Die große Frage ist wohl eher...was sind das für Simulationen? Ich würde vermuten, dass die die Übeltäter sind!

 

[Piktogramm]

Linux hält einfach alles im Ram was einmal drin ist. Die Freigabe erfolgt erst, wenn der Speicher explizit anders belegt wird. Du kannst ins Terminal einfach
free -h
eingeben. Die Spalte "used" gibt explizit an was an Ram gerade fix reserviert ist, der ganze Rest kann vom System bei Bedarf freigegeben werden.

 

[Müs Lee]

@honky-tonk: Es sind Strömungssimulationen, und ich war sehr erstaunt wie wenig RAM die im Gegensatz zu Struktursimulationen ähnlicher Knotenanzahl belegen, selbst bei großen Modellen. OpenFOAM, Acusolve, Abaqus... alle nur ein paar 100MB. Wenn die Simulation zu Ende ist, bleibt der RAM immer noch gleich voll.

@Piktogramm: Gut zu wissen, aber kann ich die Freigabe erzwingen? Das Problem ist ja, dass der RAM an sich nicht benötigt wird, also weiter belegt ist, die VM ins Speicherlimit läuft und Virtualbox mault, entweder anderweitig RAM freizugeben oder die VM neuzustarten. Ich kann nicht jedes Mal die VM neustarten wenn ich längere Simulationen laufen lasse, die an sich nicht mal 500MB im RAM belegen müssen.

 

[Piktogramm]

Eine Freigabe zu erzwingen ist nicht sinnvoll. Alles was als "cached" und "buffered" belegt erscheint ist für die Speicherverwaltung quasi frei. Wenn dir also das Gastsystem rummault, dass dir der Speicher ausgeht, dann hast du zu wenig Speicher weil mindestens ein Prozess den Speicher reserviert und damit braucht. Du kannst mit top oder übersichtlicher htop auf dem Terminal schauen welcher Task den Speicher braucht.



Ansonsten gibt es immer die Möglichkeit eine Swappartition einzurichten die entsprechend Platz zum Auslagern vorhält. Dass kann mitunter die Performance minimieren oder aber gescheit helfen.

 

[Müs Lee]

So sieht das aus:



Man sieht, dass die RAM-Belegung immer weiter ansteigt. Die 12 Prozesse zur Berechnung nutzen jeweils 0.9%, allesamt 158-161MB je Thread, macht etwa 1.9GB für alle 12 Prozesse. Die Belegung ist von Beginn bis Abbruch der Simulation (eben Freeze der Gast-VM) um 6GB angewachsen und ich sehe in top nichts, was so viel belegt.

Prinzipiell läuft es so ab: Die Simulation läuft und alle n Sekunden Simulationszeit wird ein Ausgabeordner gespeichert. Da ich diese nicht alle brauche, wird der vorletzte Ordner gelöscht und so weiter. Für jeden nicht gespeicherten Schritt der Simulation wird natürlich auch Platz benötigt, aber anscheinend nicht freigegeben. Auch nach Ende der Simulation bleibt er belegt! Windows zeigt mir auch keinen Prozess, der so viel Speicher braucht. Virtualbox ist mit 215MB der größte Verbraucher.

€dit: Gerade lasse ich testweise ein paar Simulationen laufen und momentan gibts kein Volllaufen, es kommt nicht immer vor.

 

[Piktogramm]

Wie gesagt, Linux wird alles an Daten was mal im Ram war dort cachen bis der Speicher anderweitig gebraucht wird. Das macht Windows ähnlich. Entsprechend muss der Host 24GB + 1-2GB Overhead freien Speicher bereitstellen können wenn die VM läuft. Ansonsten wird der Gast halt abschmieren wenn er keinen Speicher mehr bekommt. Wenn die Simulation nicht so viel braucht, gibt halt nur 8-16GB an den Gast und beobachte das Verhalten.

Wenn du dich für die Speicherbelegung interessierst solltest du Tasks/Prozesse nach Speicherbelegung sortieren

 

[Müs Lee]

Wie kann man Linux denn beibringen, vor Erreichen des Limits schon Speicher freizuschaufeln? Hostseitig ist mit 32GB genug vorhanden und der restliche Speicher ist nicht voll, sprich Overhead wäre da. Vorher lief die VM auch mit 16GB, aber da ich hin und wieder ins Limit lief, habe ich auf 24 erhöht.

Sortiert habe ich jetzt (Linux ist immer noch Neuland), momentan warte ich auf erneutes Vorkommen des Phänomens.

 

[Piktogramm]

Wie du Linux Caching und Buffering abgewöhnt müsstest du selber suchen. Du du da aber tief in Systemfunktionalitäten eingreifst würde ich erwarten, dass das ganze nicht all zu simpel wird.
Ist wie gesagt Unsinn und ich beschäftige mich damit nicht. Wenn der Gast abschmiert, weil der Host keinen freien Speicher mehr liefern kann, dann ist das das Problem und nichts Anderes. Inwieweit der Taskmanager von Windows wirklich anzeigt, wieviel Speicher belegt ist weiß ich nicht. Typischerweise bieten der Ressourcenmonitor der mehr Details als der Taskmanager. Mich würde nicht wundern, wenn der Ressourcenmonitor weit eher vermeldet, dass er keinen Speicher mehr hat, den er frei zuteilen kann und das auch etwa der Zeitraum ist, zudem dir deine VM abschmiert.

 

[Müs Lee]

Hm gut, dann lasse ich das. Ich musste eh feststellen, dass die Performance bei parallelisierten Simulationen äußerst schlecht skaliert und ich habe die VM im Verdacht. Entweder lasse ich die Sachen nur noch über den Cluster laufen oder konvertiere die Scientific Linux-VM zu einem realen System, mal schauen.

 

[simpsonsfan]

Was heißt denn in dem Fall "es skaliert äußerst schlecht"?
Ich meine, CFD skaliert meines Wissens nach meist besser als Struktursimulationen und ich habe jetzt auch keine Erfahrungswerte zu OpenFOAM im speziellen bzw. zu dem Verfahren und Modell, dass du nutzt.
Ich würde aber mal pauschal sagen, dass 12 Kerne für CFD irgendwo um den Faktor 8-11 schneller als einer sein sollten.

Sonst musst du halt mal testen, ob es sich bei normal installiertem Linux (ohne VM) besser verhält. Dass die VM grundsätzlich für Performance-Einbußen sorgt, klingt ja nicht abwegig.

 

[Müs Lee]

Beispiel: Lid-driven cavity flow 2d, 1000x1000 Zellen, Reynoldszahl = 1000, 0.05s Simulationszeit, Löser für Druck und Geschwindigkeit ist der geometrisch-algebraische Multigrid-Algorithmus (GAMG), physikalischer Solver pisoFoam. Ich habe über ein anderes Forum herausgefunden, dass ich nicht die Anzahl der Threads als Vorgabe zur Parallelisierung nutzen soll, sondern die Anzahl der Kerne. Stand leider nirgends explizit und da ich mich alleine da reinarbeite, mache ich noch ein paar Fehler.

Mit dem Wissen nerve ich mich die Tage mal den Cluster. Der Speedup ist leider nicht so toll wie gedacht, das liegt aber wohl einerseits am Algorithmus selbst, am Solver und an der Zellenanzahl. Wie sehr die virtuelle Umgebung ausmacht, muss ich noch herausfinden.

 

[andy_m4]

dass ich nicht die Anzahl der Threads als Vorgabe zur Parallelisierung nutzen soll, sondern die Anzahl der Kerne.

Kommt aber auch ganz drauf an, was hier konkret gemeint und gebraucht wird.

Threads in dem Sinne wie da gemeint, meint vermutlich(!) Simultaneous Multithreading (kurz SMT), welches von Intel vor ewigen Zeiten in die CPUs integriert wurde. Dabei wird ermöglicht auf einem Kern tatsächlich zwei Threads parallel laufen zu lassen, was aber auch nur dann funktioniert, wenn von den Threads der Ablauf auf unterschiedliche Funktionseinheiten aufgeteilt werden kann. Ansonsten ist der Speedup eben nicht dementsprechend, da sich die Threads gegenseitig ausbremsen.

Bei den Prozessoren von AMD die auf der Bulldozer-Architektur beruhen hat man kein SMT, sondern man hat für die Threads tatsächlich 2 Integer-Einheiten spendiert. Da heißt das dann auch nicht Kerne, sondern Modul. Leider gilt die Parallelausführung pro Modul nur, wenn tatsächlich Integer-Operationen durchgeführt werden. Bei SSE/Fließkomma gibts pro Modul nur eine EInheit und ist daher im Modul nicht parallelisierbar.

Um die Verwirrung zu vollenden wurden/werden bei diesen AMD-CPUs im Verkauf auch gerne mal nur die Anzahl der Integer-Einheiten angegeben (klingt halt besser) und das dann aber noch als Kerne/Cores bezeichnet.

Intel wiederum schafft dadurch Verwirrung, dass eben nicht bei allen CPUs SMT (aka Hyperthreading) angeboten wird.

In VirtualBox kannst Du übrigens festlegen, wieviel CPU-Kerne dem Gast-System zugewiesen werden sollen. Bei Rechenintensiven Sachen sollten das natürlich möglichst alle sein.

Was das RAM-Problem angeht. RAM kann nur von der Anwendung freigegeben werden, welche es reserviert hat. Linux kann nicht einfach so RAM freigeben, da es nicht weiß, welchen Teil davon das belegende Programm noch benötigt und welchen nicht. Ein erzwingen (was sich auch nur umständlich realisieren lässt) würde höchstwahrscheinlich zum Absturz des betreffenden Programms führen.

Dir bleibt also im ersten Schritt nichts weiter übrig als erstmal zu "tracen" wer da viel RAM in Beschlag nimmt. Und je nachdem, wer, kann man dann evtl. Maßnahmen ergreifen das Problem zu lösen. Alles andere ist nur "stochern im Nebel".

 

[Piktogramm]

Bei einer VM alle CPU Kerne durchzureichen muss nicht zwingend gut für die Performance sein. Das Hostsystem braucht genauso CPU-Zeit und da kann es durchaus von Vorteil sein dem Hostsystem exklusiv Kerne zu reservieren und wenn es ein Einzelner ist. Die Kontextwechsel auf der CPU sind vergleichsweise zeitaufwendig. Wobei Windows10 (bei mir als Gastsystem) die unschöne Angewohnheit ständig irgendwas auszuführen kommen da sehr viele Kontextwechsel.

Ansonsten ist VirtualBox kein Leistungswunder was I/O-Zugriffe angeht. Ohne Frage schnell genug für den Alltag, aber von den Topwerten einer guten SSD auch weit entfernt. Es kann daher schneller sein weniger I/O parallel laufen zu lassen.


Ob der Spaß mit SMT skaliert hängt (bei Intel) stark davon ab, wie gut die CPU Sprünge und Speicherzugriffe vorhersagen kann. Je besser das gelingt, desto weniger bringt SMT. Im Extremfall kann der Mehraufwand für das Threading die Performance unterm Strich verschlechtern. Bei dir ist es aber zu viel, als das es nur dieser Effekt sein wird.

 

[Müs Lee]

In VirtualBox kannst Du übrigens festlegen, wieviel CPU-Kerne dem Gast-System zugewiesen werden sollen. Bei Rechenintensiven Sachen sollten das natürlich möglichst alle sein.

Es sind natürlich alle Kerne zugewiesen worden.

@ Piktogramm: Es war ja mit Leistungsverlusten zu rechnen, wenn ich das alles in einer VM laufen lasse. Google förderte allerdings keine Zahlen zutage, da wurde meist von 5% gesprochen und wahrscheinlich die Desktopumgebung gemeint ohne großartige CPU-Last. Zu HT/SMT: Das bringt laut diesem PDF http://www.dtic.mil/get-tr-doc/pdf?AD=ADA612337 im Falle von OpenFOAM fast nichts.

 

[simpsonsfan]

Die relativ geringe Modellgröße dürfte sich hier auch schon auf die Skalierbarkeit auswirken (wobei auch das nicht immer sein muss, an unserer Uni arbeitet ein Institut viel mit Discontinuos-Galerkin-Verfahren, die wohl selbst bei tausenden Kernen und nur noch 1 Zelle pro Rechenkern nahezu perfekt skalieren - das entspricht dann aber quasi auch einem FE-Ansatz auf jeder Zelle mit entsprechendem Rechenbedarf.)
Wenn du sechs Kerne hast, würde ich auch nicht mehr als sechs Prozesse verwenden. Wenn nämlich pro Kern eben nur eine Floating-Point-Unit (oder VPU, wie auch immer) vorhanden ist, die bei der Strömungssimulation eigentlich permanent ausgelastet ist, wird Hyperthreading nichts mehr bringen.
Dann eher noch die übrigen Threads quasi für das Hostsystem frei lassen.
Ob übrigens HT im Bios aktiviert ist oder nicht, hat meiner Erfahrung nach (für FEM) keinen Einfluss, solange man eben immer nur einen Thread pro Core verwendet. Dabei kann man normalerweise darauf vertrauen, dass OMP die Thread Affinity automatisch richtig setzt. Oder es alternativ halt manuell vorgeben, keine Ahnung, inwieweit das bei OpenFOAM bereits gesteuert wird.

 

[Müs Lee]

Die Größe ist natürlich relevant, klar. Ich habe als Richtwert gefunden, dass der GAMG-Algorithmus bis runter auf 100k Zellen pro Prozess ordentlich skaliert, Preconditioned (Bi-)Conjugate Gradient bis 10k Zellen. Prinzipiell ist GAMG eine Ecke schneller als PCG bei niedrigem Parallelitätsgrad. Mit letzterem muss ich noch experimentieren, und bisher habe ich fast ausschließlich mit GAMG gerechnet, weil es für die bisherigen kleinen Modelle eben schneller war. Der Fokus lag allerdings auf der Einarbeitung in FVM/CFD, daher war die Performance zweitrangig. Jetzt läuft OpenFOAM aber auch auf dem Cluster und nun sollte ich das nicht mehr vernachlässigen. Bisher galt bei allen CAE-Programmen "Anzahl Threads = Anzahl Prozesse", da die Dauer egal war, ich es nicht besser wusste und mich niemand verbesserte. Resultate vor Effizienz Mal sehen, was Abaqus und Acusolve zur Performance sagen...

€dit: Acusolve legt ein ähnliches Verhalten an den Tag, also besser "Anzahl Kerne = Anzahl Prozesse" machen anstatt Threads.