You are here: Foswiki>Applications Web>AppOnCallDutyMain (20 Jun 2022, JuttaFitzek)Edit Attach

On-call duty / Rufbereitschaft - Main Page

These pages collect necessary information for on-call duty. Relevant information about system access, location of log files, restart/reboot operations and support for specific applications is all collected or linked here.

0. General information

Handout Rufbereitschaft

How-To: Arbeitszeiten und Rufbereitschaft

Duties additionally to actual on-call duty

  • Visit HKR once or twice a day and ask for issues. Spend more time there in case of problems.
  • Monitor OLOG entries
    • Shift and technical defects (Shift and Cone icon)
  • Visit the "Mittagssitzung" (12:45Uhr, Kühlschrank) and be ready to report about APP OLOG entries
  • Visit "OCM Meeting" on wednesdays (9:00Uhr, Kühlschrank) if neither JF nor HH is going, be ready to report on issues listed in the Technical Defect Report (OLog Login required)


1. System access

1.1 Citrix (works fine)

Citrix: Use your computer at home and with the Citrix client Software to access GSI. To enable Citrix access follow these instructions.

From the Terminal Server to which you logon, you can then use either Remote Desktop to your Windows machine or X-Win-32/X2go to the Linux Cluster.

1.2 X2Go (works fine)

See AppOnCallDutySystemAccessX2Go.

1.3 Remote Desktop (works fine)

To get to your own machine through lx-pool, you can use a ssh tunnel. On MacOS or Linux, entering the following command on the command line:
ssh -L

where 54321 is an arbritray local port, and belpcxxx is your machines hostname. On Windows, Putty provides similar functionality (and probably other tools as well).

Then, you can run a remote desktop client directly from the machine where you opened the tunnel. Be sure to specify the locally mapped port (54321 in the example above) as the one to connect to. From a windows environment, you can use Remote Desktop, from a Linux environment rdesktop. To enable remote desktop access follow these instruction

RDP Test Access to new RHEL / Rocky 8 Cluster

If you want to test the new RHEL / Rocky 8 Cluster, you can connect with a remote desktop to (default RDP port). Please make notes of any feedback (e.g. performance, missing software etc.), we will collect it for IN at some point in time.

During the test period there are still some restrictions:
  • The "HOME" directory is shared, so be mindfull if you edit something with newer software on the Rocky 8 Cluster
  • No prepared /common/usr (however we copied some of our scripts (like mkws) )
  • New empty scratch directory
  • You might have to ignore certificate problems, the test system has a new certificate that your system probably is not able to verify.

In addition to eclipse-2020-06 also the new eclipse-2021-06 is provided.

An example of my configuration for connecting is shown here (it still shows the old test VM, change the vmlb017 address to asl751-rc1:

Screenshot of Windows Putty and Remotedesktop configuration

The Central IT also has a detailed explanation that can be consulted:

SSH-Tunnel für Remote-Zugriff auf GSI-Windows-Geräte.

Using rdesktop from a linux mashine

Tunnel must have been set up before using port forward or sshuttle.

Minimal example

rdesktop -g 100%

With some tweaks:

rdesktop -p - -g 2560x1440 -D -N -r clipboard:PRIMARYCLIPBOARD

-p -: Prompt for password on shell, skips login screen, allows copy/paste
-g  : Define screen geometry
-D  : Do not use window decorations
-N  : Sync Num-Lock state
-r clipboard : Make clipboard work better

1.4 Igel ThinClient (works fine, but lacking features)

Using a dedicated box at home provided by GSI IT, the Igel ThinClient. Via VPN you are directly connected to a GSI Windows Terminal Server. This solution works fine, however since it is only a ThinClient, Media like Webcam etc. is not supported. For Video Conferencing you need additionally e.g. your private computer.

1.5 System access to the development or production cluster

From inside the GSI environment, you can use XWin32/X2Go from Windows systems or ssh -X from linux systems to access the asl cluster (currently asl7xx for development and asl3xx for production).

1.6 Working locally using linux based host OS

To work on a local machine one can tunnel all services throug lx-pool using ssh. The script provided by Andreas simplifies the needed steps. However, when starting applications this might become a bit slow campared to remote desktop sessions since more context information need to be donwloaded to the local host.

1.7 HowTo mount the windows file share on the asl7xx cluster

See AppOnCallDutyWindowsShareOnCluster.

1.8 HowTo use multiple screens on the asl7xx cluster

See AppOnCallDutyUseMultipleScreens.

2. Misc

2.1 Tools

For readout of FESA devices, the FESA Explorer can be used:

The Prophelper for readout of Device Access devices can be started as follows: Remember to select the virtual accelertor, which corresponds with the sequence number (at least 2018).

Tool to show device informations:
/common/usr/cscofe/bin/pdex GS12MU3I Setting -s p3

Tool to show LSA context informations:

# on the dev cluster asl4xx - shows pro information
/common/usr/lsa/bin/lsa_residump [-t]

Alternatively open:

3.0 DeviceControl

See AppOnCallDutyDeviceControlApp.

4. SchedulingApp

See AppOnCallDutyInfoSchedulingApp.

5. BSS Control

  • Setzen von RepetitionCounts für Patterns
  • Signale setzen, die Ausführbarkeit von Patterns steuern
Hier könnten typischerweise Fehler auftreten, die mit LSA oder BSS (insbesondere Komponente !RequestProcessor) zu tun haben. Außerdem wird mit Hilfe einer Subscription der MASP-Status abgefragt.

5.1 Tipps im Fehlerfall

  • Information für MASP ist unknown (grau): Graylog prüfen, ob Probleme mit Subscription vorliegen. Prüfen, ob MASP läuft (z.B. MASP-Gui / Interlock-Programm). Wenn der Verdacht besteht, dass der MASP nicht läuft/keine korrekten Daten liefert etc.: Timing-RB.
  • Informationen für Signals sind unknown (grau): Graylog prüfen, ob Zugriff auf RequestProcessor -REST-API funktioniert. Wenn der Verdacht besteht, dass der RP nicht läuft/keine korrekten Daten liefert etc.: BSS-RB (Services)

6. RequesterApp

  • Anforderung von Strahlzielen: Daueranforderung (jede Ausführung, die möglich ist), Einmalanforderung (genau einmal ausführen (unter Berücksichtigung des Repetition Counts!)), Anforderung zurücknehmen/abbrechen
Hier könnten typischerweise Fehler auftreten, die mit BSS (insbesondere Komponente !RequestProcessor) zu tun haben, und mit der Konfiguration von Strahlzielen.

6.1 Konfiguration von Strahlzielen

Im Config-File der RequesterApp auf websvcdev/websvcpro (/common/usr/cscoap/htdocs/config/ wird konfiguriert, welches Strahlziel auf bestimmten Rechnern/Konsolen angefordert werden kann:


Achtung: HKR- und Experiment-Konsolen ohne, ASL-Maschinen mit !

Achtung: Dumps (z.B. HHD) sind implizit immer angefordert, sie sind nicht an-/abforderbar. Es ergibt daher keinen Sinn, sie auf Rechnern als Strahlziel zuzuordnen.

Eine erfolgreiche Zuordnung erkennt man daran, dass die RequesterApp unter "Strahlanforderung" gut sichtbar das jeweilige Strahlziel (z.B. HTP) und mehrere Buttons für die Anforderung anzeigt, wenn sie auf einem bestimmten Rechner gestartet wird. Fehlt im Config-File die Zuordnung für einen bestimmten Rechner, so fehlt in der Anwendung, wenn sie auf dem betreffenden Rechner gestartet wird, sowohl die Anzeige des Strahlziels als auch die Buttons. In der Anwendungskonsole sollte eine entsprechende Fehlermeldung erscheinen, z.B. "Für Konsole [Rechnerbezeichnung] wurde kein zugeordnetes Strahlziel gefunden, fehlende Konfiguration." o.Ä. .

7. ParamModi

See AppOnCallDutyInfoParamModi.

7b. Storage Ring Mode App


See AppOnCallDutyInfoStoRiMo.

7c. Digitizer App

See AppOnCallDutyInfoDigitizerApp

8. Zusammenarbeit mit Timing-Rufbereitschaft

  • Gespräch mit Dietrich und Michael (Matthias ist derzeit krank, Montag, 11.06. wieder da)
  • INIT ist Grenzfall, kann aber auch von kompetenten APlern gemacht werden, man sollte wissen, was man macht
  • "Durchcyclen" führt im Gegensatz zu Init zu Datenverlust, spätere Analyse schwieriger
  • "Durchcyclen" oder FCGA-Reset sollte nur von Timing Gruppe durchgeführt werden

9. LSA

Fehler aus LSA können verschiedene Ursachen haben:
  • Model (David & Co.)
    • Fehlermeldungen wie "out of limits"
  • Netzwerk
    • Fehlermeldungen wie "Method Invocation Exception" (RMI Fehler)
      • Anwendung neustarten
      • prüfen ob LSA-Server läuft (meist auf asl341)
        ps -u belsvc -o pid,%cpu,%mem,lstart,command
      • Abhängigkeiten (Versionen von LSA) überprüfen
        • entweder unter About in der Anwendung (falls verfügbar) oder /common/usr/cscoap/htdocs/applications/<app-name>/current/lib
      • SErver neustart (falls nötig) über IN Rufbereitschaft
  • Performance Probleme
    • Datenbank auf hängende Jobs überprüfen (evtl IN Rufbereitschaft)

Wenn kein Timing läuft (überprüfen mit Snoop-Tool)
  • BSS
    • signale überprüfen
    • Neustart (wenn nötig) über IN Rufbereitschaft
      • anschliesend Vollversorgung aus Scheduling App
  • MASP überprüfen
    • Beam Modes korrekt gesetzt? (in ParamModi suchen nach beam_mode)
    • Neustart (wenn nötig) über IN Rufbereitschaft
      • anschliesend Vollversorgung aus Scheduling App
  • Patterns aus und wieder einplanen
    • DM status über FESA-Explorer (cmwpro00a -> tsl017)

9.0. LSA Server Release

Folgende Projekte sind zu releasen:
  • lsa-ext-fair-gsi
  • lsa-server-gsi
Bei RB wird idR. nur "lsa-ext-fair-gsi" geändert (Modell, Berechnungen). Einfache Bugs (z.B. Javadoc-Bugs, ggf. auskommentieren) fixen. Wie folgt vorgehen:
  1. pull von lsa-server-gsi und lsa-ext-fair-gsi
  2. lsa-ext-fair-gsi: mvn release:prepare release:perform
  3. uU. java docs fixen oder kommunizieren
  4. lsa-server-gsi: lsa-ext-fair-gsi Abhängigkeit hochzählen
  5. lsa-server-gsi: release (s.o.)
  6. lsa-server-gsi: rollout
    rollout --dest /common/usr/cscoap/opt
    Rollout of Services and Applications
  7. Info an HKR: keine Eingaben möglich, keine Trims machen während Deployment
  8. Infrastruktur RB Anrufen: LSA Server neustarten
  9. Info an HKR: wieder ok

Debugging von Makerules:
  • lsa-ext-fair-gsi -> lsa-server-gsi -> parammodi-app SNAPSHOT Abhängigkeiten eintragen.
  • lsa.mode=2 und pro Konfig
  • Dann kann man die make rules debuggen
  • Debugger nicht unnötig im Breakpoint stehen lassen da trim lock solange besteht!
DB Änderungen

In der Regel durch: AS, RM, HH
eigentlich nie in der RB, sollte auch nur durchgeführt werden, wenn man sich damit auskennt!
  1. LSA Server stoppen lassen
  2. lsa-db-scripts, lsa-db-pro
  3. LSA Server starten lassen

9.0.1 Hierarchie-/Parameteränderungen

Änderungern an der Hierarchie oder bei Parametern werden idR. tagsüber gemacht! Dazu ist ebenfalls die direkte Absprache mit dem HKR erforderlich oder es wird ein Wartungsfenster benötigt. Dafür auch das common-lsa-utils-uilib-Projekt ausgechecken. Hier werden ggf. neue Oberflächentexte hinzugefügt, die z.B. im Parammodi angezeigt werden.
TIP Falls die Sprachbundles nicht kurz vorher geändert wurden, ggf. beim Modellierer nachfragen. Wenn Sprachelemente nicht geändert werden, muss man solange mit den "kryptischen" Benenennungen auskommen.
Die Modellierer müssen angeben, welche Applikation(en) neu released werden müssen (Parammodi, SchedulingApp).
ALERT! NICHT VERGESSEN: Abhängigkeiten hochziehen!
Mit dem HKR ist immer abzustimmen, wenn die Applikationen neu ausgerollt werden: Vor dem Neustart müssen die alten Applikations-Instanzen vorher beendet werden. Ansonsten können Inkonsistenzen auftreten!
TIP Mit "What'sApp" kann man feststellen, welche der Applikation(en) wo laufen.

9.1. BP_DELETION_ERROR : Failed delete_beamprocess_action

Sollte es beim Versuch, Kontexte zu Löschen, zu Fehlern der folgenden Art kommen:
BP_DELETION_ERROR : Failed delete_beamprocess_action with bp id 73730, Err: ORA-00001: unique constraint (LSA.BP_NAME_UK) violated ORA-06512: at "LSA.SETTINGS_MANAGEMENT", line 1504

So liegt das daran, dass in diesem Kontext ein Beam Prozess enthalten ist, der den gleichen Namen trägt, wie ein anderer Beam Prozess, der am gleichen Tag gelöscht wurde. (Beispiel: Es wurde ein Pattern "ABC" erstellt, gelöscht, ein neues Pattern "ABC" erstellt, gelöscht -> gelöschte Beam Prozesse tragen gleichen Namen). Da Beam Prozesse nicht sofort gelöscht werden, sondern zunächst nur als zu löschend markiert werden, kommt es zu einer Constraint-Verletzung wegen des gleichen Namens. Das sollte normalerweise kein Problem sein, da dem Namen eine Nummer angehängt wird, die hochgezählt wird. Allerdings kann es in seltenen Fällen, wenn sehr viel gelöscht wird, dazu kommen, dass die Nummer überläuft, und dann kommt es doch zu gleichen Namen und Fehlern.

  • kurzfristig: Eventuell reicht, es einfach nochmal zu probieren. Ansonsten zu löschenden Kontext umbenennen und dann löschen. (Vermutlich ausreichend gute Lösung für einen RB-Einsatz!)
  • sauberer: Services-RB rufen und darum bitten, dass der Job zum Löschen der "gelöschten" Beam Prozesse händisch angestoßen wird. (Vermutlich während RB nicht unbedingt notwendig. Der Job läuft normalerweise täglich gegen 8:00 Uhr.)

9.2. Probleme mit BSS und Timing

Bugs in BSS, Data Master, und der Kommunikation zwischen diesen Komponenten bzw. zwischen LSA und diesen Komponenten können dazu führen, dass sich das gesamte System "verklemmt". Das äußert sich z.B. darin, dass das System nicht mehr reagiert (Fehlermeldungen beim Ein- und Ausplanen von Patterns, beim Deaktivieren von Patterns, usw.) oder inkonsistent ist (z.B. scheint ein Pattern gemäß der Infos im BSS Control nicht ausführungsfähig zu sein, an den Events im Snoop Tool erkennt man jedoch, dass es läuft) usw.

9.2.1 Bekannte Ursachen LZMA Decompression Exception / Input Stream Error (Februar 2019)

Der Timing Master wirft u.U. eine Exception, wenn mehrfach hintereinander die gleiche Aktion auf den gleichen Daten ausgeführt wurde. Dies erkennt man daran, dass es im Graylog Exceptions z.B. aus der Scheduling App, BSS Control, dem Request Processor, etc. gibt, die als Cause "Decompression: LZMA reported ERROR DATA" beinhalten.

Die Behandlung erfolgt durch einen Reset des BSS in Zusammenarbeit mit der Timing-RB.

11 Feb 2019 15:02:00,510 Fehler beim Aktualisieren der PatternGroups 
 java.lang.RuntimeException: An error occurred while trying to execute the 'dump' command on the Generator. See diagnostic logging for more information.
 <b>Caused by:</b>
   cern.japc.ParameterException: Decompression:<b> LZMA reported ERROR DATA (1)</b>
 <b>Caused by:</b>
   cern.cmw.rda3.common.exception.ServerException: Decompression:<b> LZMA reported ERROR DATA (1)</b>

Wenn bereits bem Schreiben ein Fehler aufgetreten ist, dann sieht die Meldung etwas anders aus. Die Behandlung ist identisch.
A-Priori Verify for LZMA compression failed, Decompression:<b> LZMA reported ERROR DATA </b>(1)

Am 01.03. wurde die LZMA Library ausgebaut. Am 04.03. trat ein höchstwahrscheinlich verwandter Fehler mit dem Exception-Text "input stream error" auf:

cern.japc.ParameterException: *input stream error* at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
<b> Caused by:</b> 
   cern.cmw.rda3.common.exception.ServerException:<b> input stream error</b> at cern.cmw.rda3.common.util.ExceptionUtils.createRdaServerException(

Es wird vermutet, dass dieser Fehler die eigentliche Ursache ist und auch bereits der Auslöser für die LZMA Exceptions war. Solange die LZMA Library ausgebaut ist, wird statt LZMA Exceptions ggf. dieser Fehler in Logs angezeigt. Die Behandlung ist identisch. "Outdated Context" exception

Kann dazu führen, dass gesamte PatternGroup steht, da "disabled by LSA" Signal gesetzt ist, nachdem Drive fehlgeschlagen ist, weil der mitgesendete Kontext veraltet war (z.B. veraltete Längen, veraltete User/Selektoren, etc.).

Vermeidung: Regelmäßiges Refreshen von Anwendungen, explizites Refresehen nach Kontrollsystem-Reset.

Behebung: Erfolgreiche Versorgung eines Patterns aus der PatternGroup über LSA, z.B. Vollversorgung/Drive aus neugestartetem oder per (Client-)Refresh aktualisiertem ParamModi.

9.2.2 Fehlerbehebung

Vorher: Kontakt zu Services-Rufbereitschaft bzgl. BSS und zu Timing-Rufbereitschaft bzgl. Generator/Data Master. Problem besprechen.
Per Tool

Der Reset kann durch das Tool expert-cs-panic-app (Prototyp!) durchgeführt werden.


Falls Reset durchgeführt werden soll:
  1. Ist-Zustand dokumentieren, um ihn später wiederherstellen zu können (eingeplante Patterns, Unilacanforderungen, gekoppelte Patterns, aktivierte Patterns/Pattern Groups - z.B. Screenshots von Scheduling App oder BSS Control, inkl. Koppel-Dialog im BSS Control).
  2. Im BSS Control z.B. per "Pattern deaktivieren" ALLE Patterns deaktivieren. (Hintergrund: Es könnte sonst sein, dass nach dem Wiedereinplanen einzelne Patterns SOFORT loslaufen, falls das BSS noch veraltete Signal-Infos hat!)
  3. Reset-Vorgang:
    • Falls gekoppelte Patterns vorhanden: BSS Control aus aktuellen Release-Branch auschecken. Im pom.xml Dependency auf die letzte Stable-Version von lsa-server-gsi eintragen. BSS Control aus dem Workspace starten mit den unten angegebenen VM-Parametern. Oben rechts "Patterns koppeln" anwählen und alle entkoppeln.
    • Scheduling App aus aktuellen Release-Branch auschecken. Im pom.xml Dependency auf die letzte Stable-Version von lsa-server-gsi eintragen. Scheduling App aus dem Workspace starten mit den unten angegebenen VM-Parametern. Alle Patterns ausplanen (aus Pattern Groups entfernen und oben rechts Supply/Versorgen klicken).
    • [Parallel: Timing-RB setzt Generator/Data Master zurück, evtl.: Services-RB setzt Request Processor und Director zurück.]
  4. Wenn Schritt 3 vollständig erledigt (auch von anderen RBs):
    • Scheduling App aus dem Pro-Launcher starten. Dort alle gewünschten Patterns wieder einplanen* und oben rechts Supply/Versorgen klicken.
      • * Beim Einplanen ist ggf. zu berücksichtigen, dass bestimmte laufende Experimente z.B. ihren Virtuellen Beschleuniger für den SIS18 (S... im ContextWidget) behalten wollen. Dies kann über die Einplanungsreihenfolge gesteuert werden (es wird immer der nächste freie Virtuelle Beschleuniger genommen). Ggf. beim HKR nachfragen. Notfalls alle Patterns einzeln nacheinander einplanen, in der Reihenfolge der angegeben Virtuellen Beschleuniger für SIS (S..) und ESR (E..) (beide nutzen den gleichen Zahlrenraum).
    • BSS Control aus dem Pro-Launcher starten. Dort Kopplungen wiederherstellen. Ggf. in Schritt 2 deaktivierte Patterns wieder aktivieren.
  5. Client-Refresh in allen offenen ParamModi-Anwendungen (sonst steht LSA evtl. nach nächster Versorgung! siehe OutdatedContextException), am besten auch SchedulingApps neustarten.

Die Schritte 4 und 5 können ggf. auch von den Operateuren durchgeführt werden, das muss nicht durch uns geschehen.

Zu verwendende VM-Parameter:

Die Programme können auch entsprechend konfiguriert gestartet werden:
webstart --quiet --config=pro --vmargs="-Dlsa.mode=2 -Dlsa.bss.generator.dataSupplyEnabled=false -Dlsa.bss.director.dataSupplyEnabled=false -Dlsa.bss.requestProcessor.dataSupplyEnabled=false"

webstart --quiet --config=pro --vmargs="-Dlsa.mode=2 -Dlsa.bss.generator.dataSupplyEnabled=false -Dlsa.bss.director.dataSupplyEnabled=false -Dlsa.bss.requestProcessor.dataSupplyEnabled=false"

Sollte das Programm auf diese Weise Fehler werfen (z.B. veraltete MakeRules) muss auf den aktuellen Release-Branch zurückgegriffen werden und per Eclipse oder mvn exec:java -D... gestartet werden.

10. Quellenprogramm

Beim Fortran-(!) Quellenprogramm muss u.U. auf eine frühere Version zurückgegriffen werden. Dafür muss die RB von Betriebssoftware UNILAC wissen, wo die vorher verwendete Version liegt. Im Acc-6 Cluster im Verzeichnis /common/usr/cscosv/bin-repos/op-aps/iq-co/write/dflt-i386 befinden sich alle vorhandenen Vorgängerversionen, der Link develop zeigt auf die aktuelle Version. (Wenn man auf eine vorhergehende Version zurückgehen will, muss man den Link develop ändern. Gestartet wird ausschliesslich von den Kollegen RB von Betriebssoftware UNILAC).
Die derzeitige Rückfallversion ist die vom Juli 2016.

11. Profilegrid App

See AppOnCallDutyInfoProfilegridApp

12. RemoteLauncher service

Der RemoteLauncher -Service läuft auf jeder Konsole, Dort wird er bei jedem Start der Konsole mitgestartet. Er wird automatisch neugestartet, wenn der Prozess beendet wurde,

Falls der Dienst nicht mehr über WhatsApp neugestartet werden kann, so muss er beendet werden, um ihn automatisch neu zu starten.
  1. Service-Prozess ermitteln (Aktuell steht dort: PROCESS_ID ManagedRemoteLauncherServer)
  2. Dienst beenden
kill -9 PROCESS_ID

13. HowTo

13.1 Rollout

Falls eine neue SW-Version ausgerollt werden muss, ist das vorher mit dem Schichtleiter im HKR abzustimmen. Sollte ein Ausrollen bis zur nächsten Mittagssitzung nicht möglich sein, bitte ein kurze Info an Regine. Sie wird das dann bei der täglichen Mittagssitzung vorbringen, damit ein geeigneter Zeitpunkt dafü festgelegt werden kann. Sollten dann immer noch nicht alle erreicht worden sein, die darüber Bescheid wissen müssten, werden diese per Email informiert.

13.2 "Vollversorgung"

Eine "Vollversorgung" aus der Scheduling App heißt: Alle Patterns einer Pattern Group (oder sogar alle Patterns in allen Pattern Groups) ausplanen, versorgen ("Versorgen / Supply" oben rechts), gewünschte Patterns wieder einplanen, versorgen. Ob eine oder mehrere Pattern Groups betroffen sind, muss der RBler einschätzen (wenn z.B. 2 von 3 Pattern Groups fehlerfrei arbeiten, sollte man zunächst versuchen, nur die eine fehlerhafte neu zu versorgen, etc.).

Eine "Vollversorgung" in Bezug auf Geräte / LSA-Settings findet aus ParamModi statt: Kontext auswählen, unten bei "An Geräte schicken" stattdessen über Dropdown "Ganzen Kontext schicken" wählen. Mehrere Kontexte ggf. nacheinander abarbeiten (kann z.B. notwendig sein, wenn ein Gerät neu zugeschaltet oder resettet wurde - dann müssen alle Kontexte, in denen dieses Gerät Settings haben kann, neu versorgt werden.)

13.3 Diagnose bei OutOfMemory-Errors

Wenn bei einer Anwendung Fehlerverhalten auftritt (hängt, zeigt falsche Infos an, ...), bei dem man den Verdacht hat, dass ein vollgelaufener Speicher der Grund sein könnte oder man den Anwendungszustand genau analysieren möchte, dann kann ein Heapdump nützlich sein.

Wenn möglich: Heapdump erzeugen und zukommen lassen. Falls das Problem im HKR auftrat und man selbst nicht vor Ort sein kann, je nach HKR-Besetzung die folgenden Schritte durchführen lassen.

13.3.1 Prozess-ID ermitteln

Zum Beispiel durch eine der beiden Alternativen:

Mit Hilfe von Graylog (s.u.) oder durch den Operateur über das terminal auf der Konsole: jps und nach dem Programmnamen schauen. Beispiel:

2529 DigitizerExpertApp
28707 Jps
486 LauncherApp

Bei der DigitizerExpertApp wäre dies die PID 2529.

13.3.2 Heap Dump erstellen

jmap -dump:live,format=b,file=<filename>.hprof <PID>

Zum Beispiel: jmap -dump:live,format=b,file=/tmp/dump_digitizer_expert_app_tcl1030.hprof 2529

Dump auf den Cluster bringen (benötigt Cluster-Account):
scp /path/to/<dump-filename> <username>@asl74<n>:/tmp

(n ist dabei die gewünschte asl Instanz. Bei dem Verzeichnis /tmp muss auch auf der passenden asl nach der Datei geschaut werden. Statt /tmp kann auch z.B. /scratch/dump verwendet werden.)

Zum Beispiel: scp /tmp/dump_digitizer_expert_app_tcl1030.hprof awalter@asl744:/tmp

Es kann sein, dass noch der Dateizugriff durch den Operateur gewährt werden muss:

ssh <username>@asl74<n>
chmod a+rw <filename>

Die Dump-Datei dann bitte aus dem /tmp oder /scratch Verzeichnis z.B. ins eigene Home-Verzeichnis umziehen, damit sie nicht automatisch gelöscht werden kann. Nach erfolgter Analyse kann die Datei dann gelöscht werden.

Analyse z.B. mit jvisualvm , Eclipse Memory Analyzer, …

13.3.3 Nachvollziehen der Fehler im Graylog

Häufig werden OOMs von unserem Uncaught-Exception-Handler erwischt. Wenn man im Graylog einfach so nach "OutOfMemoryError" sucht, werden diese Fälle oft nicht gefunden. Stattdessen unter Verwendung von RegEx suchen nach:


13.4. Diagnose hängender Anwendungen

Analog zum Heapdump kann ein Thread-Dump einen guten Überblick über den Stand der Anwendung geben. Ein Abzug kann mit folgendem Befehl gemacht werden.

jstack PID  > /tmp/thread-dump-example-app_tcl1030.txt

PID Ermittlung und Dateitransfer wie oben in Abschnitt 11.3 zur „Diagnose bei OutOfMemory-Errors“.



-- JuttaFitzek - 16 Aug 2017

I Attachment Action Size Date Who Comment
2021-04-21_RDP-dev-test-vm.pngpng 2021-04-21_RDP-dev-test-vm.png manage 1 MB 27 Apr 2021 - 09:03 RaphaelMueller RDP Config Example to Test Development Machine
Topic revision: r84 - 20 Jun 2022, JuttaFitzek
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback