offener Betatest für neue cmsearch VM Anwendung

[paparazzipeter]

Hallo Michael,
nach den Informationen u.a. im RNA-Forum bewegte ich mich immer im "gesetzlichen" Rahmen und meiner bisher gemachten (beschränkten) Erfahrungen . . . aber ich stimme Dir zu : Weitere Experimente werde ich auf die 2. Maschine verlegen, habe ich in anderen Sachen auch gemacht. Die erste längere RNA-WU habe ich auf PC2 auch so gestartet und erfolgreich abgeschlossen.
Werde also die "fehlerhafte" WU löschen und die anderen nach und nach starten - mal sehen, ob ich welche überleben.
Gruß
Peter

[paparazzipeter]

Ergebnis des Rettungsversuchs: Habe von der Sicherung 2 Versuche gemacht, a) ohne und b) mit vorherigem Löschen der defekten VM im VirtualBox-Manager (ein Refresh der VM war nicht möglich, der Fehlertext entsprach wohl dem, der im Fehler-Log steht), jeweils nur die betroffene Task gestartet. Beide Versuche führten zu einem Berechnungsfehler. Danach habe ich von den ursprünglichen 6 Tasks eine nach der anderen gestartet - alle 6 laufen weiter !
Entweder kann man was aus dem Fehlertext erkennen (naheliegend), oder man stellt Vermutungen an auf Grund des Verhaltens der Task.
Warum ist die Task nicht sofort mit hoher Priorität (wie die schon laufenden 6 Tasks) gestartet worden, auch wenn nebenher einige WCG-Tasks liefen (von denen dann eine verdrängt worden wäre) ? Warum kam zwischendurch die Meldung "Warten auf Speicher", obwohl sowohl auf der Platte als auch im Arbeitsspeicher mehr als genug Platz war ?
Was passiert, wenn sich eine VM-Task in einem nichtaktiven Zustand befindet, alle Tasks angehalten werden und BOINC heruntergefahren und danach wieder gestartet wird mit Neustart aller Tasks ?
Vor dem Fehler hatte ich das System - mit BOINC vorher runter - durchgestartet.

[Michael H.W. Weber]

Ich antworte mal auf das, was ich kommentieren kann - Christian sollte da nochmal etwas detaillierter nachfassen.

Warum kam zwischendurch die Meldung "Warten auf Speicher", obwohl sowohl auf der Platte als auch im Arbeitsspeicher mehr als genug Platz war ?

Woraus schließt Du, dass Du genug Speicher hattest? Im Taskmanager wird nur die VM-Steuerung angegeben, nicht der RAM-Bedarf der einzelnen RNA World Aufgaben.

Was passiert, wenn sich eine VM-Task in einem nichtaktiven Zustand befindet, alle Tasks angehalten werden und BOINC heruntergefahren und danach wieder gestartet wird mit Neustart aller Tasks ?

Nach meinem Kenntnisstand werden die Taks ohne Probleme wieder aufgenommen. Ich hatte es allerdings vor vielen Wochen mit einer Vorgängerversion unserer VM getestet - müßte also nochmal von jemandem wiederholt werden, der gerade eine neue WU gestartet hat (um den hoffentlich nicht zu befürchtenden Verlust zu minimieren).

Michael.

[paparazzipeter]

Als erklärter Nicht-Fachmann sowohl für den Task-Manager als auch die interne Speicherbedarfskalkulation des BOINC-Systems unter besonderer Beachtung der Nutzung von VM's habe ich nur den Versuch gemacht, etwas anzumerken, was mir als Abweichung vom Normalgeschäft ins Auge gefallen war.
Bei der Anmerkung über realen und virtuellen Speicher fiel mir spontan der Witz über den Hühnertransporter ein, bei dem der Fahrer zwischendurch immer anhielt, ausstieg und mit einem Stock die Hühner im Laderaum aufscheuchte und diese wild in der Luft herumflatterten. Von einem hinter ihm Fahrenden angesprochen antwortete der Mann: Das zulässige Gewicht des LKW sei zu gering, so dass er zwischendurch durch das Aufscheuchen einige Hühner in die Luft bringen müsse.
Bei meinem "LKW mit 32GB Arbeitsspeicher und ausreichend Plattenplatz" und einem im Task-Manager angezeigten Verwendungsverlaufs des physikalischen Arbeitsspeichers von ca. 12 - 13 GB bin ich als Nicht-Fachmann davon ausgegangen, dass man da "sowohl auf dem Boden als auch in der Luft noch einige Hühner unterbringen könnte".
Ausserdem habe ich das so verstanden, dass die Entwicklung der Nutzung von VM's im Zusammenhang mit dem BOINC-System noch nicht abgeschlossen ist und somit jeder Hinweis eine Hilfe sein könnte.

[Norman]

Ich denke Michael wollte dich bestimmt nicht irgendwie "anzicken" sondern war bestimmt wieder erschrocken dass schon wieder etwas mit der VM nicht richtig laufen könnte.
langsam sollte sie das nämlich. natürlich sind hinweise und gedankenspiele jeder art immer willkommen und auch hilfreich und werden gerne angenommen. danke dafür.
leider zeigt der taskmanager den tatsächlichen ramverbrauch der applikation nicht direkt an. wenn man im taskmanager unter leistung schaut wird einem gesamte ramverbrauch angezeigt und so kann man
sich ungefähr ein bild davon was tatsächlich so verbraten wird ( peaks gibts immer mal ).
da die xxl doch oft ordentliche brummer sind wurden beim plattenplatz und ram-bedarf großzügige werte voreingestellt so dass dies nicht der "crashfaktor" oder sonstiges hindernis sein sollte.

aber bleib am ball


Norman

[ChristianB]

Ich kann leider auch nichts weiter zur Klärung beisteuern. Anscheinend hat der Client irgendwas komisches gemacht als du die app_config.xml erstellt hast und das gefiel dem vboxwrapper überhaupt nicht. Im Logfile des einen gemeldeten Tasks steht leider nichts hilfreiches außer das die VM nicht registriert werden konnte. Das kann natürlich auch eine externe Ursache haben mit der der vboxwrapper nicht gerechnet hat. Rom Walton kümmert sich im neuen Jahr um die ganzen Fehlermeldungen welche jetzt so aufgelaufen sind, aber es steht auch ein größerer Umbau des vboxwrapper an. Und zwar soll die Registrierung der VM direkter erfolgen als zur Zeit. Also genau die Stelle die hier fehlgeschlagen ist.

[paparazzipeter]

Ich fühlte mich in keiner Weise "angezickt" !

Wünsche allen einen guten Rutsch ins hoffentlich erfolgreiche Jahr 2014 !!!

[Michael H.W. Weber]

Mit 32 GB RAM bist Du allerdings in der Tat überdurchschnittlich ausgestattet. Ich muss diese Arbeitsspeichergröße wohl irgendwo überlesen haben. Bei 8 Kernen mit je einer Vm WU sollte davon maximal nur etwas mehr als die Hälfte verbraucht werden, sodass keine Probleme zu erwarten sind - vorausgesetzt, Du hast ein 64 Bit OS (wovon wohl auszugehen ist, da alles andere Mumpitz wäre).
Und ja, natürlich kann man die Gesamtbelegung des Speichers im Taskmanager sehen.
Bei wenigen der ganz großen WUs bin ich mir allerdings ehrlich gesagt immer noch nicht sicher, wieviel RAM sie maximal benötigen, da dies leider nicht vorhergesagt werden kann.
Es gab beispielsweise eine CMBUILD-WU, die benötigte 128 GB RAM.
War allerdings die absolute Ausnahme...
Guten Rutsch!

Michael.

[paparazzipeter]

Der Xeon ist eine 12-Core CPU, bei der ich z.Z. aber nur 14 (logische) freigegeben habe. Auf 6 liefen bisher RNA-Tasks, die 7. machte Probleme und musste aufgegeben werden. Die 6 "geretteten" konnte ich von einer aktuellen Sicherung wiederbeleben - von denen ist mittlerweile 1 fertig. Die restlichen Cores (bis max. 14) sind mit WCG-Tasks beschäftigt. Speicherauslastung um die 50%.
Das System ist Win7-64bit, sonst hätte ich wohl keine Tasks erhalten. Das mit dem Taskmanager war mir klar (es gibt auch andere Analyse-Werkzeuge) und da ich die Maschine laufend beobachte (wegen der RNA-Beta-Tasks), war ich um so überraschter, dass die 7. RNA-Task ein solches Verhalten an den Tag legte (7,5 h Rechenzeit mit ungewöhnlichen Unterbrechungen). Habe versucht, die Sicherung auf meiner 2. Maschine zu starten, aber die Kontrollen in der Software haben das bemerkt und die Tasks entweder mit Rechenfehler abgebrochen oder als nicht mehr brauchbar klassifiziert. Ein Eingriff in die BOINC-Kontroll-Files wäre zu aufwändig und wahrscheinlich zu kompliziert gewesen. Ich hatte gedacht, ich käme auf diesem "einfachen" Wege an den letzten brauchbaren Fehler-Log von der besagten 7. Task - aber da war der Wunsch der Vater des Gedankens . . .
Guten Rutsch
Peter

[paparazzipeter]

Schlechte Nachrichten : 2 von meinen 5 Tasks sind ausgestiegen. Mir war aufgefallen, dass alle 5 Tasks seit ca. 8-10h keine Checkpoints mehr geschrieben hatten. Wenn ich sie einzeln angeklickt habe, kam bei 2 nicht der Button "Zeige die VM-Konsole" - das waren aber erstaunlicherweise nicht die, die später ausgestiegen sind. Im Taskmanager waren von den 5 nur noch 4 aktiv - der 5. hatte wohl den Anschluss verloren. Die restlichen 3 laufen nach dem Durchstarten der Maschine mit Fortschreiben der %-Werte normal weiter.
6330806/14923554 : Gemäß Stderr-Log scheint diese Task schon am 29.12. "gestorben" zu sein - da fehlt anscheinend der Teil bis 31.12.
6330948/14923289 : sieh LOG
Meine Daten : RNA-User-ID: 11175; Host-ID (PC1): 27790.
Neben BOINC habe ich keine Experimente auf der Maschine durchgeführt !!!
Ich habe den Eindruck, dass, wenn eine Task Probleme bekommt, andere mit runtergerissen werden.
Durchgeführte Sicherungs-Aktivitäten (Anhalten der Tasks, beenden BOINC mit Zeitzuschlag, Sicherungs-Kopie vom BOINC-Daten-Ordner erstellen und BOINC wieder starten: zuerst die RNA-Tasks bis diese laufen, dann die WCG-Tasks): 29.12. um 19:05 Uhr ; 31.12. um 08:34 Uhr (Daten der Sicherungs-Dateien).

[paparazzipeter]

Noch schlechtere Nachrichten: Mittlerweile sind alle Tasks ausgestiegen. Habe mir die Mühe gemacht, mich durch meine Sicherungen und die diversen stderr-Files zu arbeiten.
M.E. gibt es in diesen Files diesmal einige Stellen, an denen der Fachmann Ansatzpunkte für eventuelle Schwachstellen finden kann.
Zur Zeit lasse ich meine Maschine unter Volllast (24 log. Kerne) mit WCG-Tasks auslaufen, um festzustellen, ob hardwareseitig eventuell Schwachstellen existieren (ein gleichartiger Test mit Klimamodellen zeigte Stabilität). Sollte es zielführend sein, kann ich auch nur RNA-Tasks laufen lassen ohne jegliche sonstigen Aktivitäten.

[ChristianB]

Die sind alle ausgestiegen weil die Snapshots nicht mehr gelöscht werden konnten. Das Problem habe ich schon öfters gesehen aber womit das zusammen hängt weiß ich auch nicht. Der Ursprung scheint immer eine fehlgeschlagene Aktion mit Fehlercode -182 zu sein. Das gilt es erstmal abzuklären. Du brauchst nichts an deinem System zu verändern. Einfach ganz normal weiterlaufen lassen. Eventuell kannst du ja die app_config.xml wieder löschen. Wenn wieder eine VM aussteigt dann reicht es wenn du uns mitteilst was kurz davor passiert ist (Neustart/Absturz).