offener Betatest für neue cmsearch VM Anwendung

[Dunuin]

P.S.: Die totale Systemausbremsung erlebe ich auch bei nur zwei parallalen VM WUs und zweien von Einstein@home.

Das hatte ich bei meinem Phenom II x4 955 ja auch schon berichtet.

[Norman]

deshalb habe ich 1 core leider abgeschaltet.
wenn 1 core brach liegt funktionierts besser und trotzdem sind 4 kerne ordentlich ausgelastet.
vielleicht jede menge overhead ?

[yoyo]

Ich hatte auch schon berichtet, dass bei 8 VM auf meinem 8 thread system die Kiste nicht mehr bedienbar ist und schon bei 4 VM zu 100% ausglastet ist, wobei das System selbst 50% davon beansprucht.
Daher möchte ich auch nicht alle RNAworld Apps in die VM verlagern, sondern nur die cmsearch XXL. App. Die anderen sollten wir native lassen.
yoyo

[Beorn]

Diese Beobachtungen kann ich nicht bestätigen (um auch einmal etwas Positives zu berichten ). Auf einem FX-8350 (8 Threads) laufen zur Zeit 4 RNA VMs und 4 recht speicherintensive Gamma-ray-pulsar-search von Einstein@home, außerdem WUProp. Obwohl ca. 6 von 8 GB RAM belegt sind, ist das System problemlos zu bedienen und jede Workunit nutzt rund 13% CPU, so wie es sein soll.

Übrigens: Auf dem Rechner, welcher wg. der aufgeblähten stderr Probleme machte (mittlerweile habe ich insgesamt rund 1,2 GB Dateiinhalt gelöscht), bekam ich gestern zwei weitere Workunits. Diese laufen ebenfalls parallel mit der bisherigen, also ingesamt drei VMs parallel. Der i7-3720QM (max. 8 Threads) hat z.Zt. ebenfalls Einstein laufen (nur 3 Workunits) und WUProp. Auch hier kein ungewöhnlicher Overhead, CPU-Auslastung rund 77% wie erwartet. Ab und zu Anstieg auf rund 84% wenn einer der drei VBoxManage.exe Prozesse sich regt.

Bis jetzt (toi-toi-toi ) übrigens kein extremes Anwachsen der drei stderr.txt, aktuell nur 15+15+20 KB. Schau'n mer mal.

Um die Anzahl der RNA VMs zu begrenzen, kann ich eine app_config.xml empfehlen, Bsp.:

Code: Alles auswählen

<app_config>
	<app>
		<name>cmsearch3</name>
		<max_concurrent>4</max_concurrent>
	</app>
</app_config>

Es fällt desweiteren auch auf, das bei der neuen Workunitserie von gestern viele Abbrüche wg. fehlender Virtualisierungsfeatures (nicht vorhanden oder nicht angeschaltet) aufgetreten sind. Vielleicht sollte man darauf noch mal deutlich hinweisen (sticky post hier und irgendwas Auffälliges auf der Website)?

[Michael H.W. Weber]

Um die Anzahl der RNA VMs zu begrenzen, kann ich eine app_config.xml empfehlen, Bsp.:

Code: Alles auswählen

<app_config>
	<app>
		<name>cmsearch3</name>
		<max_concurrent>4</max_concurrent>
	</app>
</app_config>

Aha. Ein weiteres Indiz, dass es sich lohnen könnte, dafür einen universellen Editor zu entwickeln, der die einzelnen Felder erklärt?

Es fällt desweiteren auch auf, das bei der neuen Workunitserie von gestern viele Abbrüche wg. fehlender Virtualisierungsfeatures (nicht vorhanden oder nicht angeschaltet) aufgetreten sind.

Wie muss ich das verstehen? Wo muss ich da noch manuell irgendwas an- oder abschalten?

@Yoyo: So pauschal kann ich mich dem nicht anschließen. Es sollten meiner Meinung nach ALLE Apps in die VM, die lang genug laufen, um Checkpoiting zu benötigen. Momentan ist das in der Tat in erster Linie CMSEARCH XXL, aber auch CMCALIBRATE kann gegelgentlich dauern. Wir sollten daher vielelicht die ohne Checkpointing maximal akzeptable Laufzeit festsetzen.

Zu meinen WUs (vgl. oben):
-anhalten und wieder laufen lassen funktioniert einwandfrei, egal ob nur eine, zwei oder alle WUs parallel angehalten werden
-wenn ich statt der möglichen 4 VM WUs nur 3 laufen lasse, ist das Problem des scheintoten Systems gelöst, ergo könnte man die Zahl der Kerne auf der jeweiligen Kiste ermitteln, eins abziehen und dies als maximal parallel laufbare VM WUs definieren. Oder aber man löst die Ursache, warum es hakelt anders - wenn es denn geht. Denn sich ein Verwaltungskern zu leisten ist natürlich vergeudete Power.
-Abschalten und Wiederstarten des BOINC Managers führt zunächst mal (bei 3 VM WUs) zu erheblichem Plattengerödel, bevor die CPU-Last überhaupt mal im Taskmanager sichtbar ansteigt. Zwei der drei WUs werden auch gleich mal mit Berechnungsfehler abgebrochen.

Code: Alles auswählen

O_O
 |
(__)

Michael.

[yoyo]

Ich hatte das mit Christian schonmal im Chat diskutiert. Aus meiner Sicht ist die maximale Laufzeit ohne Checkpoint ca. 24-48h, bei Christian wohl so eher bei 4-8h. Ich kann dazu nur sagen, dass ich eine WU mit 24h Laufzeit ohne Probleme auf meinem Laptop laufen lassen würde (der geht eh nur in den Standby und wird nicht ausgeschaltet), aber eine VM oder gar mehrere davon kann ich da nicht laufen lassen, da das System dabei unbedienbar wird. Das man da irgendwas einstellen kann ist ja schön. Aber ich möchte mein System nicht ständig Babysitten, es soll einfach laufen. Daher deaktivier ich dann lieber die VM App.
Aus meiner Sicht am Besten wäre, serverseitig (ich glaub aber das geht nicht) die Anzahl parallel laufender VM auf AnzahlCpu/2 begrenzt.

yoyo

[Beorn]

Aha. Ein weiteres Indiz, dass es sich lohnen könnte, dafür einen universellen Editor zu entwickeln, der die einzelnen Felder erklärt?.

Ich finde die app_config.xml ist im Gegensatz zur altbekannten app_info.xml recht überschaubar und leicht zu erstellen / editieren. Link #1 (Berkeley) / Link #2 (SG)

Es fällt desweiteren auch auf, das bei der neuen Workunitserie von gestern viele Abbrüche wg. fehlender Virtualisierungsfeatures (nicht vorhanden oder nicht angeschaltet) aufgetreten sind.

Wie muss ich das verstehen? Wo muss ich da noch manuell irgendwas an- oder abschalten?

Ich habe gesehen, dass ChristianB dazu heute einen ausführlichen Newseintrag verfasst hat. Zum einen muss die CPU es unterstützen. Die entsprechenden CPU-flags, welche beim BOINC-Start auch als Processor features gemeldet werden, lauten vmx für Intel und svm für AMD. Fast alle in den letzten 10 Jahren verkauften 64bit CPUs sollten es können. Zum anderen muss das BIOS es aber auch unterstützen / freischalten. Bei Desktop-Mainboards bietet das BIOS-Menü diese Option fast immer an. Bei Notebooks wird es aber leider manchmal eingespart und wenn die Features dann nicht per Default an sind, guckt man in die Röhre.

-Abschalten und Wiederstarten des BOINC Managers führt zunächst mal (bei 3 VM WUs) zu erheblichem Plattengerödel, bevor die CPU-Last überhaupt mal im Taskmanager sichtbar ansteigt. Zwei der drei WUs werden auch gleich mal mit Berechnungsfehler abgebrochen.

Ich habe es mir grundsätzlich angewöhnt, beim Schließen von BOINC Manager und Apps vor dem Editieren von Dateien oder erneutem Starten per Taskmanager zu prüfen, ob auch alles beendet wurde. Das scheint bei VMs noch wichtiger zu werden. Bei mir benötigen die Prozesse immer einige Sekunden bis sie gestoppt sind, am längsten benötigt VBoxSVC.exe (schätzungsweise 10 bis max. 15 Sekunden).

Gruß

[Michael H.W. Weber]

-wenn ich statt der möglichen 4 VM WUs nur 3 laufen lasse, ist das Problem des scheintoten Systems gelöst

Hmmm, das muss ich korrigieren: Es MUSS ein Kern VöLLIG idle sein, damit der VM-Satz an WUs (übrigens egal wie viele) ohne Störung des Systems (im Sinne dessen, was Yoyo sagt) abgearbeitet werden kann. Also: Es ist definitiv ein Verwaltungs-Kern notwendig. Möglicherweise ist diese Anforderung architekturabhängig?
Ich hatte Einstein@home zugeschaltet und nur eine VM WU laufen lassen. Das System verhält sich exakt so hakelig, wie wenn ich 4 VM WUs laufen lasse.
Woran liegt das?
Ich habe den Verdacht, dass es dieses "Oracle Ding" ist, was stört.
Oder aber es gibt Einstellungen an meinem System bzw. der VM-Installation, die ich noch nicht checke.

Michael.

[ChristianB]

Aus meiner Sicht am Besten wäre, serverseitig (ich glaub aber das geht nicht) die Anzahl parallel laufender VM auf AnzahlCpu/2 begrenzt.
yoyo

Aus meiner Sicht wäre das auch am besten aber leider kann man auf dem Server nur eine feste Zahl angeben die dann ähnlich wie die Methode von Beorn mit der app_config.xml auf dem Client funktioniert. Die Methode ist aber auch nicht für jeden geeignet weil man dafür ja wissen muss wo man die Datei erstellt.

@Beorn: kannst du mal bitte eine kleine Anleitung fertigmachen, das würde ich gern mit in eine kommende FAQ reinstellen. Die legen wir am besten im Wiki an.

[Michael H.W. Weber]

-wenn ich statt der möglichen 4 VM WUs nur 3 laufen lasse, ist das Problem des scheintoten Systems gelöst

Hmmm, das muss ich korrigieren: Es MUSS ein Kern VöLLIG idle sein, damit der VM-Satz an WUs (übrigens egal wie viele) ohne Störung des Systems (im Sinne dessen, was Yoyo sagt) abgearbeitet werden kann. Also: Es ist definitiv ein Verwaltungs-Kern notwendig. Möglicherweise ist diese Anforderung architekturabhängig?
Ich hatte Einstein@home zugeschaltet und nur eine VM WU laufen lassen. Das System verhält sich exakt so hakelig, wie wenn ich 4 VM WUs laufen lasse.
Woran liegt das?
Ich habe den Verdacht, dass es dieses "Oracle Ding" ist, was stört.
Oder aber es gibt Einstellungen an meinem System bzw. der VM-Installation, die ich noch nicht checke.

Michael.

So, auf einem Intel i7 habe ich dieses Problem nicht: Dort werden alle Kerne mit VM WUs oder Einstein belegt und es kommt bisher nicht zu merklichen Betriebsstörungen. Daraus folgt, dass es ein architekturabhängiges Problem sein dürfte. Wenn das so ist, macht es auch keinen Sinn, pauschal auf CPU-Kerne/X zu begrenzen, sondern man sollte das je nach System dynamisch festsetzen.

Ein Restart des AMD-Systems ließ diesmal keine VM WUs krepieren. Die Laufzeiten wurden allerdings erneut erheblich nachkorrigiert - und können so keinesfalls korrekt sein.
Die Kiste hat übrigens tatsächlich ebenfalls Virtualisierungseinstellungen im BIOS, die aber auch aktiviert sind.

Michael.

[ClaudiusD]

Hab mir das jetzt auch mal ein paar Tage angeschaut. Bei meinem i7 (wie bei Michaels) gibt es keine Probleme. Momentan laufen auf allen "8" Kernen die VMs mit RNA, nebenbei für die Grafikkarte Folding@Home.

Das Einzige was mich wundert: Im Prozessmanager stehen 8 von den WUs, verbrauchen völlig korrekt rund 12-13% CPU und etwa 58-60mb Ram. FAH benötigt ca 700mb insgesamt (sind mehrere Prozesse). Dennoch komme ich insgesamt auf 11,8gb. Nicht dass mich das groß stören würde, bis 16gb können die sich von mir aus ausbreiten. Aber wundern tut mich der hohe Speicherbedarf schon - vor allem weil er nicht nachvollziehbar ist.

[ChristianB]

Die vom Manager angezeigte verbleibende Laufzeit errechnet sich aus den FLOPS Schätzungen des Servers. Die Fortschrittsanzeige errechnet sich aus den FLOPS Schätzungen auf dem jeweiligen Rechner und wird bei 98,765% gehalten falls zu niedrig geschätzt wurde. Anscheinend kommt mein kleiner Algorithmus nicht mit hohen Laufzeitschätzungen zurecht das werde ich für die nächste Version mal korrigieren müssen.

@Plonk: Die VM wird mit mehreren VBox Prozessen gestartet unter anderem VBoxHeadless. Man muss je nach Anzeige des Taskmanagers eventuell den Speicherverbrauch mehrerer Prozesse addieren.

Auf meinem AMD 2 Kerner (mit Linux) habe ich in der Testphase auch zwei VM parallel laufen lassen und keine Probleme festgestellt.