offener Betatest für neue cmsearch VM Anwendung

[Michael H.W. Weber]

Ich bezweifle auch, dass man außerhalb der VM den genauen Speicherbedarf der App selbst noch nachvollziehen kann?

...das wäre aber natürlich sehr wünschenswert.

Michael.

[Beorn]

Hmm... könnte man dies nicht bei Bedarf in das shared-Verzeichnis hinein reporten?

[Matthias Lehmkuhl]

Aktuell sehe ich im ProcessExplorer einen echten Speicherbedarf von weniger als 100 MB (Working Set) während des überwiegenden Teils der Laufzeit.

Wenn Du den gesamten belegten Speicher analysierst, dürftest Du sehen dass die VM weitaus mehr belegt als jene < 100 MB. Siehe auch die von Jacob Klein in der Newssektion geposteten Links.

Danke für die Links, habe jetzt den VMMap von Sysinternals gefunden, danach nutzt der VBoxHeadless.exe tatsächlich 1,2 GB Speicher, davon 1 GB "Private Data" die der ProcessExplorer nicht anzeigt.

Bisher war es bei cmsearch immer so, das insbesondere bei den langlaufenden WU zum Ende der Berechnung sehr viel mehr Speicher genutzt wurde.

Da cmsearch hier auf einem Debian Linux innerhalb einer VM läuft ist nicht mehr nur der Speicherbedarf der App selbst relevant für Performance des Wirtssystems und BOINC-Scheduling. Ich bezweifle auch, dass man außerhalb der VM den genauen Speicherbedarf der App selbst noch nachvollziehen kann?

Debian Linux an sich hat schon Möglichkeiten die Speichernutzung von Prozessen zu dokumentieren.
Ob diese aber auch z.B. auf das Shared Verzeichnis exportiert werden können, kann ich ad hoc nicht sagen.
Die VM an sich benötigt natürlich auch Resourcen, zusätzlich zum cmsearch Prozess.

[yoyo]

Wenn innerhalb der VM der Speicherbedarf steigt (durch z.B. cmsearch), dann sollte auch außerhalb der VM im hosting OS der Speicherbedarf steigen.
yoyo

[ChristianB]

VirtualBox alloziert ja dynamischen RAM für die VM aber maximal 4GB. In der VM stehen aber von Anfang an 4GB zur Verfügung. Es läuft der cmsearch Prozess und das Controlscript welches alle 30 sec den freien Speicher der VM abfragt. Diesen Wert könnte man in den shared/ Ordner schreiben (bzw: 4GB minus freemem = usedmem). Das hilft aber dem BOINC Manager nicht viel weil der nichts damit anfangen kann. Wenn der Client selbst den aktuellen Speicherverbrauch ermitteln will ist das nur umständlich möglich wie Matthias schon herausgefunden hat. Für BOINC ist es wichtig das die VM mit 4GB geführt wird damit keine weitere Aufgabe gestartet wird und dann eventuell nicht genug Speicher zur Verfügung steht wenn die VM plötzlich mehr haben will. Von daher ist es besser davon auszugehen das die VM 4GB belegt auch wenn das nicht der Fall ist.

Aktuell benutze ich den freemem Wert im Controlscript dazu die VM abzubrechen wenn der freie Speicher innerhalb der VM unter 100MB sinkt. Damit muss diese Aufgabe mit einer anderen VM gestartet werden die mehr RAM zugewiesen bekommt. Das ist dann aber eine Einzelfallentscheidung sollte der Fall auftreten.

[Michael H.W. Weber]

Debian Linux an sich hat schon Möglichkeiten die Speichernutzung von Prozessen zu dokumentieren.

Aha. Auf so eine Äußerung lauere ich seit langem.
Könnten wir das nutzen, den maximalen RAM-Verbrauch bei jeder WU in eine mit den Ergebnissen hochzuladende Datei zu speichern (die nicht in den WU-Validierungsprozess eingeschlossen wird)?
Das würde uns endlich ermöglichen, empirisch eine statistisch singnifikante RAM-Verbrauchstabelle zu erstellen, die es uns ermöglichen würde, den tatsächlichen RAM-Bedarf neuer WUs wesentlich (!!!) realistischer abzuschätzen.
Damit könnten wir dann zukünftig auch verhindern, dass (1) zu wenig angefordert wird (was zu irreparablen Abstürzen führen würde) und (2) sicherstellen, dass nicht RAM belegt wird, den unsere WUs gar nicht benötigen.

Michael.

[Matthias Lehmkuhl]

Bei mir hat sich heute Nacht wieder eine "cmsearch VM (VirtualBox) 1.0.2 v1.03 (vbox64)" verabschiedet.
Meldung: Maximum disk usage exceeded
ist ein bisschen komisch,
hatte den Boinc HDD Speicher von 20 auf 40 GB erhöht, frei sind mehr als 50 GB auf dem LW.
Genutzt werden aktuell etwas über 10 GB von Boinc mit dem abgebrochenen Result wohl um die 15 GB.
Beim letzten mal schauen war auch nur der aktuelle snapshot vorhanden.
Leider kann ich nicht sagen wie groß die stderr.txt war.
http://www.rnaworld.de/rnaworld/result. ... d=14920908

Beim letzten Result auf dem Rechner ist die stderr.txt 394MB groß, nach nur 25 Std. Laufzeit.
Werde mal versuchen, die Größe der stderr automatisch zu überwachen.

[Beorn]

Meldung: Maximum disk usage exceeded
ist ein bisschen komisch,
hatte den Boinc HDD Speicher von 20 auf 40 GB erhöht, frei sind mehr als 50 GB auf dem LW.
Genutzt werden aktuell etwas über 10 GB von Boinc mit dem abgebrochenen Result wohl um die 15 GB.
Beim letzten mal schauen war auch nur der aktuelle snapshot vorhanden.

Die Workunit-Konfiguration beinhaltete bei den um den 20.10. versandten Workunits eine Begrenzung auf 6 GB, siehe client_state.xml bzw. bei laufendem Workunit im Slot auch die init_data.xml: <rsc_disk_bound>6000000000.000000</rsc_disk_bound>. Wenn dieser Wert überschritten ist, kommt es auch dann zu o.g. Fehler, wenn BOINC ingesamt noch HDD Platz zur Verfügung hat.

Beim letzten Result auf dem Rechner ist die stderr.txt 394MB groß, nach nur 25 Std. Laufzeit.

Mit der neuen Version v1.05 oder auch mit v1.03? Habe noch keine 'neuen' Wutzen, hoffte aber natürlich das der Fehler behoben ist.

Gruß

P.S.: Sehe gerade, dass es schon eine v1.06 gibt.

[Matthias Lehmkuhl]

Die Workunit-Konfiguration beinhaltete bei den um den 20.10. versandten Workunits eine Begrenzung auf 6 GB, siehe client_state.xml bzw. bei laufendem Workunit im Slot auch die init_data.xml: <rsc_disk_bound>6000000000.000000</rsc_disk_bound>. Wenn dieser Wert überschritten ist, kommt es auch dann zu o.g. Fehler, wenn BOINC ingesamt noch HDD Platz zur Verfügung hat.


Mit der neuen Version v1.05 oder auch mit v1.03? Habe noch keine 'neuen' Wutzen, hoffte aber natürlich das der Fehler behoben ist.

P.S.: Sehe gerade, dass es schon eine v1.06 gibt.

Danke für den Hinweis, habe den Wert mal von 6 auf 20 in der client_state.xml geändert, ist noch eine v1.03
Der geänderte Wert wurde auch automatisch in die init_data.xml übertragen.

Habe gestern schon 2 v1.05 erfolgreich gerechnet.
Für v1.06 gehe ich wohl erst mal leer aus.

[yoyo]

Die workunit ist mit einem disk limit von 6000000000 (ca. 6GB) ausgestatet, wenn der erreicht ist bricht Boinc die WU mit obigem Fehler ab.
Wenn wir davon ausgehen, dass die Langläufer 4GB RAM belegen und bei einem Snapshopt auf die Platte geschrieben werden und dass während des snapshottens ja noch der vorherige snapshot auf der Platte liegt, dann müßten es mindestens 8GB disk limit sein. Hinzukommen ja noch die initialen Dateien der Workunit und zum Snashot kommen noch die Inhalte der Platte der VM. Daher würde ich das disk limit wohl eher auf 10GB setzen wollen.

yoyo

[Eisfelder]

Was bedeutet diese Fehlermeldung?

13.11.2013 12:36:13 | RNA World | Output file cmsvm_GA-p[BR-Lin64f]_2_Bacillus-amyloliquefaciens-FZB42_CP000560.cir.EMBL_RF00638_MIR159_1384171283_608_0_1 for task cmsvm_GA-p[BR-Lin64f]_2_Bacillus-amyloliquefaciens-FZB42_CP000560.cir.EMBL_RF00638_MIR159_1384171283_608_0 absent

Virtual machine 4.2.16

[Michael H.W. Weber]

Daher würde ich das disk limit wohl eher auf 10GB setzen wollen.

Ja, das sehe ich genauso.

Was bedeutet diese Fehlermeldung?

13.11.2013 12:36:13 | RNA World | Output file cmsvm_GA-p[BR-Lin64f]_2_Bacillus-amyloliquefaciens-FZB42_CP000560.cir.EMBL_RF00638_MIR159_1384171283_608_0_1 for task cmsvm_GA-p[BR-Lin64f]_2_Bacillus-amyloliquefaciens-FZB42_CP000560.cir.EMBL_RF00638_MIR159_1384171283_608_0 absent

Virtual machine 4.2.16

Es bedeutet, dass die Ergebnisdatei nicht vorhanden ist - so wie es da steht.
Hast Du die neuste BOINC-Version drauf?
VirtualBox kannst Du ebenfalls aktualisieren (mußt es aber nicht). Der Bug in den neueren Versionen ist bei uns behoben.
Dann bitte einmal RNA World Projektreset durchführen, damit alles auf dem neusten Stand ist.

Michael.