ungeklärter Speicheranstieg bei 12-Core Xeon mit SSD

[paparazzipeter]

Grundsätzlich einverstanden, aber es könnte sehr wohl in den Bereich der VBox-/VM-Nutzung gehören.
Habe z.Z. als Maschinentest auf dem Rechner 24 Einstein-Tasks laufen mit je ca. 450 MB, 100% Auslastung, 14,5 GB Speichernutzung seit ca. 3 Stunden gleichbleibend. Damit scheidet der Rechner selbst als Ursache weitgehend aus. Als nächstes müsste ich einen Vergleich der Dienste meiner beiden Rechner durchführen, denn auf dem 2. Rechner laufen 6 VM-Tasks v1.10 speicherstabil unter VBox 4.2.16.
Vielleicht könntet ihr mal bei den VBox-Experten nachfragen, ob dort das Problem bekannt ist bzw. worin die Unterschiede der Versionen liegen, die zu solchen Phänomenen führen könnten.

[duftkerze]

ich habe mir mal die vbox 4.2.6 organisiert und lasse mal da testweise rosetta knuspern.
von rna kommt momentan nix

die vbox läuft mit 6 kernen und 8gb speicher...mal guggen was passiert.

[ChristianB]

ich habe mir mal die vbox 4.2.6 organisiert und lasse mal da testweise rosetta knuspern.
von rna kommt momentan nix

die vbox läuft mit 6 kernen und 8gb speicher...mal guggen was passiert.

Selbst wenn was verfügbar wäre würdest du innerhalb einer VM keine RNA VM Aufgaben bekommen. Das Problem was paparazzipeter hat bezieht sich auf seinen Windows-Hostrechner der VBox 4.3.6 installiert hat und dort die RNA VM Aufgaben laufen lässt. Mindestens eine davon scheint sehr Speicherhungrig zu sein. Mögliche Ursachen können jetzt bei VBox selber liegen oder aber ein Speicherleck im vboxwrapper was nur bei einer bestimmten Aufgabe auftritt (weshalb es eher unwahrscheinlich ist).

[paparazzipeter]

Den letzten Satz von Christian muss ich leider richtig stellen : Wie oben beschrieben habe ich 3 Tests gemacht : Die 7 Tasks habe ich in 2 Gruppen aufgeteilt (4 und 3). Jede Gruppe hatte das gleiche Problem, also waren mindestens 2 Kandidaten unter den Tasks (falls es überhaupt von den Tasks selbst verschuldet wird). Dann habe ich einen Einzeltest von der 1. Gruppe gemacht - wieder das Problem. Darauf hin habe ich den Gedanken einer seltenen Task nicht weiter verfolgt und mich auf die grundsätzlichen Probleme konzentriert : Anwendungen, Dienste und eventuell falsche Einstellungen auf dem Rechner - siehe meine Ausführungen vorher. Hier hatte ich zwar Erkenntnisse - aber die hatten mit der Problemlösung wenig bis nichts zu tun (z.B. Superfetch deaktivieren).

Das Hauptproblem jetzt : Im Taskmanager und Ressorcenmonitor finde ich keinen Dienst und keine sonstige Funktion, die diesen linearen starken Speicheranstieg darstellt. Ausserdem laufen die 24 Einstein-Tasks seit mehr als 7 Stunden ohne jeglichen Speicheranstieg - sogar teilweise leicht negativ.

[paparazzipeter]

Ich habe das Systemverhalten meiner beiden Rechner mal länger beobachtet :
Meines Erachtens gibt es deutliche Unterschiede, wobei mir dies besonders bei dem Prozess VBoxManage.exe auffiel.

Bei dem Rechner mit VBox 4.2.16 und v1.10 bleiben die PID's der Prozesse im 4-stelligen Bereich und scheinen auch jeweils neu benutzt zu werden (?? wenn die alte Nummer und damit der Speicher wieder freigegeben wurde ??).

Bei dem Rechner mit VBox 4.3.6 und v1.11 haben die PID's ein sehr "nervöses" Verhalten, erhöhen sogar während ihres Erscheinens im Taskmanager laufend ihre Nummer nach oben - und das in erheblichem Umfang (?? werden die Prozesse mit den niedrigeren Nummern eventuell nicht richtig beendet und der Speicher freigegeben ??). Eine Verfolgung in Richtung genutzter Dienste (werden normalerweise dann in der Liste blau markiert) scheint nicht mehr richtig zu funktionieren. Die Nacht über hat sich die PID-Nummer bis weit über die Millionengrenze erhöht (wie hoch läßt das eigentlich Windows 7 zu ?).

Habe von meiner Seite aus alles Mögliche versucht, um meinen Rechner als Ursache nach besten Wissen und Gewissen aus zu schliessen : Habe das System neu aufgesetzt, nur die nötigsten Anwendungen neu installiert, BOINC neu, Vbox 4.3.6 mit Ext.-Pack neu. Einzig die BOINC-Daten habe danach von der Sichgerung wieder eingespielt.

Heute habe ich, nach BOINC runter/rauf, das Projekt test4theorie mit einer VM.Task alleine gestartet, um festzustellen, ob die CPU im Bereich der virtuellen Unterstützung ein Problem hat. Alles OK, aber auch hier scheint es eine langsame Erhöhung des physikalischen Speichers zu geben . . .

Der Rechner mit VBox 4.2.16 hat eine RNA-VM-Task v1.11 in Warteposition. Ich will/kann diese erst anlaufen lassen, wenn der Kurzläufer (z.Z. bei 385 Stunden mit %-Grenze, läuft vielleicht 400 - 600) beendet ist. Dann könnte ich sehen, was eine v1.11 unter VBox4.2.16 macht - aber das habe andere Teilnehmer sicher schon festgestellt.

Vielleicht haben meine Beobachtungen (als Nicht-Fachmann habe ich die oben schon genannte Vermutung) nichts mit dem Problem zu tun, aber das können (mir) nur die Fachleute beantworten oder auf einem anderen Rechner ebenfalls mit dieser oder vergleichbarer Konfiguration gegenchecken. Ich werde heute noch auf dem betroffenen Rechner SMT ausschalten und testen - dann bin ich am Ende mit meinen Möglichkeiten.

[ChristianB]

Das ist wirklich komisch und klingt nach einem Problem mit Vbox bzw. dem vboxwrapper. Kannst du mir mal die aktuellen stderr.txt Dateien aus den Slotverzeichnissen schicken? Eventuell kann man da ja sehen warum so viele vboxheadless.exe Prozesse gesatartet werden. Eigentlich sollte die ProzessID über die Laufzeit konstant bleiben.

[paparazzipeter]

Es handelt sich nicht um die vboxheadless.exe Prozesse (deren Numnmern bleiben konstant), sondern um die VBoxManage.exe Prozesse, die mal auftauchen, die Nummern dann laufend wechseln und wieder verschwinden. Aus den stderr.txt in den slots sind keine Besonderheiten zu erkennen, die habe ich parallel laufend unter Beobachtung..

In welcher Anwendung wir der Prozess VBoxManage.exe aufgerufen und kontrolliert ? Wenn da ein Aufruf mit falschen Parametern oder/und eventuell anschliessenden folgenden fehlenden oder falschen Folgeaktivitäten vorliegt, dann könnte es auch zu diesem Phänomen kommen.

[ChristianB]

die vboxmanage.exe wird vom vboxwrapper aufgerufen. Und der protokolliert fein säuberlich in der stderr.txt was er macht und ob irgendwelche Fehler auftreten. Es scheint der pollt ständig irgendwas, das ist eigentlich normal. Nicht normal ist das der Speicherverbrauch dadurch in die Höhe geht. Verschwinden denn die Vboxmanage.exe Prozesse wieder?

[paparazzipeter]

Teilweise Antwort schon in der Mail.
Die Vboxmanage.exe Prozesse verschwinden zwar immer wieder, aber oft erscheint einer bzw. mehrere und die PID's wechseln dann so schnell, als ob vergebliche Versuche zur Ausführung unternommen werden (ist zwar eine gewagte Behauptung, denn der Rechner ist sicher schneller, aber man könnte den Eindruck gewinnen . . .). Ich glaube nicht, dass der wrapper das meldet, wenn zwischen solchen Versuchen (oder ähnlichen Aktivitäten) keine Ausgabe auf die Protokoll-Datei erfolgt. . . .
Falls notwendig oder wünschenswert oder sinnvoll, können wir auch mal telefonieren, dann könnte man evtl. einige Sachen schneller klären . . . oder so.

[paparazzipeter]

Frage zu VBox 4.3.6 v1.11 : In den Slots stehen zusätzlich zu den stderr- folgende Text-Files : VBox, vbox_replay und vbox_trace.
Könnte die Fachleute daraus etwas erkennen, wenn Fehler auftreten ?

[ChristianB]

Ich habe gerade einen Hotfix des vboxwrappers publiziert. Ausserdem enthält v1.12 ein paar mehr Debugmeldungen von innerhalb der VM sowie von VirtualBox selber. Das soll helfen das von paparazzipeter entdeckte Memory Leak sowie die ab und zu auftretenden "-161 result file not found" Fehler zu finden. Auch habe ich einen kleinen Schwung Aufgaben erzeugt, 12 sind aktuell noch ungesendet.

[paparazzipeter]

2 Fragen :
1. Wird für eine VM neben den 3 GB Speicher auch noch ein physischer Core reserviert ? Auf meinem 6-Kerner mit SMT laufen 6 VM's, die 7. VM will nicht anlaufen, obwohl ich auf 64 GB Mem bin.
2. Auf dem Rechner mit 4.2.16 v1.10 kann ich plötzlich keine Sicherung der Syst.-Partition mehr starten - auf dem Bild aus der Systemsteuerung erscheint nur die oberste Zeile. Ist dieses Phänomen bekannt ?