JVM Wartung und Optimierung für Sysadmins

[smox]

Hallo liebe Kollegen,

Im Bezug auf Java finde ich eigentlich immer Informationen zum Thema Java Entwicklung selbst.

Mich würde interessieren ob es Ressourcen zum Thema Wartung- und Fehleranalyse gibt.
Im Grunde wäre sowas wie Java für Sysadmins recht interessant. Nur eben nicht als Tool für Sysadmins, sondern eher wie Analyse ich das Verhalten einer JVM, wo kann ich Stellschrauben anpassen wenn meine Applikation nicht so läuft wie geplant. Wie beispielsweise erkenne ich ob eine Anwendung einfach Ressourcenhungrig ist oder ob vl wirklich ein Memory Leak vorliegt.


Eine Java Applikation ist für mich aktuell gefühlt eine Blackbox.


Würde mich freuen wenn ihr mir Feedback dazu geben könntet wo ich mich am besten in die Richtung schlau machen kann.



LG

 

[kneitzel]

Also Java selbst bietet sehr wenig und das ist auch eher uninteressant. Wenn, dann geht es doch darum, wie man z.B. die Application Server administriert. Da gibt es dann aber auch extrem viel - was aber dann auch wieder teilweise spezifisch auf eben einen Application Server ist.

Und wie willst Du ohne Wissen zu der Applikation denn unterscheiden zwischen: Applikation hat Memory Leak und Applikation braucht viel Speicher?
(Zumal ein Memory Leak extrem schwer ist, denn wir haben ja eben den GC, der aufräumt, d.h. die Speicherverwaltung läuft in der Regel eh automatisch.

 

[smox]

Und wie willst Du ohne Wissen zu der Applikation denn unterscheiden zwischen: Applikation hat Memory Leak und Applikation braucht viel Speicher?
(Zumal ein Memory Leak extrem schwer ist, denn wir haben ja eben den GC, der aufräumt, d.h. die Speicherverwaltung läuft in der Regel eh automatisch.

Das wäre eben meine Frage gewesen, ob man das von außen beurteilen kann.
Schade. Das war jetzt nicht die Antwort die ich mir erhofft habe, aber trotzdem vielen Dank für deine Zeit.

 

[tommysenf]

Also Java selbst bietet sehr wenig und das ist auch eher uninteressant.

Dem muss ich allerdings widersprechen. Java bietet in der Hinsicht eigentlich wesentlich mehr als die meisten anderen mir bekannten Programmiersprachen. Und auch ein Memory Leak in Java zu erstellen ist sehr einfach. Mit Profiling und Memory Tools kann diese dann auch gut finden. Auch um z.B. Ursachen für Dreadlocks zu erkennen sind sie sehr nützlich. Generell kann es nicht Schaden seine Anwendung mal durch einen Profiler zu jagen um zu messen ob es Stellen gibt an denen sich vielleicht wirklich eine Optimierung lohnt...

Hier findest du eine Übersicht über Monitoring Tools die mit dem JDK ausgeliefert werden:

Monitoring Tools

docs.oracle.com

Java Mission Control

JDK Mission Control

Java Flight Recorder

Java Flight Recorder – So funktioniert das Java Profiling Tool

Der Java Flight Recorder ist mit einem echten Flugdatenschreiber vergleichbar. Die auf ihm gespeicherten Informationen werden wichtig, wenn etwas schief gelaufen ist. Mit seiner einheitlichen Datenbasis hilft der Flight Recorder außerdem Administratoren und Entwicklern dabei, gemeinsam an...

jaxenter.de

Visual VM

VisualVM

docs.oracle.com

JConsole

JConsole

docs.oracle.com

Ansonsten es natürlich auch eine Menge alternativer kommerzieller oder freier Tools. Stichworte für Google wären hier:
Java Monitoring
Java Profiling

Ich denke jeder professionelle Java Entwickler sollte zumindest auch einen Profiler in seinem Tool Repertoire haben mit dem er umgehen kann.

 

[kneitzel]

Das sind aber dann alles Werkzeuge für den Entwickler und nicht für den System Administrator.

@smox hat explizit bezüglich SysAdmin Rolle gefragt. Und sorry: Was soll der SysAdmin denn dann sagen? Der schaut auf den Profiler und sagt: Da braucht die und die Routine recht lange. Ob und wie man da etwas drehen kann ist nicht sein Bier. Wie läuft das denn in der Praxis? Es wird ein Problem identifiziert. Laufzeit, Speichernutzung, was auch immer scheint problematisch zu sein oder ist problematisch. Dann wird der SysAdmin natürlich mit gewissen Tools ran gehen. Aber das sind dann keine eigenständigen Analysen sondern dient lediglich dazu, dass die Entwickler die Probleme nachvollziehen können. Und dann können die Entwickler das Problem hoffentlich beheben.

 

[tommysenf]

@JustNobody Wir sind hier im Bereich Enterprise Java. In den meisten Projekten in denen ich tätig war existiert ein meist sogenanntes Operations Team welches unabhängig von den Entwicklern ist und nur für den reibungslosen Ablauf der Anwendung und Optimierungen setzt. Und deren tägliches Brot ist unter anderem der Einsatz genau solcher Monitoring Tools.
Auch hat er denke ich genau danach gefragt, denn sein Anliegen ist ja einen Blick in die "Black Box" JVM zu werfen. Und genau hierfür bietet Java entgegen deiner Aussage sehr viel an...
Und wenn du seine Frage richtig liest steht da ja gerade: "Nur eben nicht als Tool für Sysadmins, sondern eher wie Analyse ich das Verhalten einer JVM ..."

 

[kneitzel]

Das wir im Bereich Enterprise Java sind, ist klar. Mich würde da wirklich mal interessieren, was genau euer Team da macht und mit welchem Wissen bezüglich der Applikation.

Oder sind das dann doch eher ein Application Server spezifisches Monitoring / Optimieren?

 

[tommysenf]

Gleich mal vorweg, mir geht es hierbei nicht darum Recht zu haben oder irgendjemanden zu überzeugen. Aber falls es dich wirklich interessiert versuche ich es mal grob zu umreissen.
Ich denke Operations kann man am besten damit beschreiben dass sie das System orchestrieren. Eine Unternehmensanwendung besteht ja im allgemeinem nicht aus einer Applikation sondern ist ein Zusammenspiel aus vielen eigens entwickelten, zugekauften und Stadardsoftware. Weiterhin finden auch ständig Änderungen statt, da auch der Konzern sich wandelt. (Unternehmenszukäufe, Umstrukturierung etc.)
Als praktisches Beispiel eines Projektes kann ich dir zum Beispiel das zentrale Teilemanagement eines der weltgrößten Automobilhersteller nennen. Hier dran hängt so ziemlich alles von den Produktionsbändern über die Lieferanten bis hin zu jeder kleinen Autowerkstatt die ein Ersatzteil ordern möchte. Operations sorgt sozusagen dafür das das Ding läuft. Hierzu zählen unter anderem:

- Einspielen von Updates und Patches
- Hauptverantwortung für das MDM
- Failover und Desaster Strategien implementieren
- Für ausreichend Ressourcen sorgen
- Ansprechpartner für den Support
- Last und Performance Tests des Systems und der Komponenten untereinander
- Konfiguration von Schnittstellen
- Verwaltung der Staging Areas
- Fahren von ETL Prozessen

Natürlich geht es auch um Application Server Monitoring. Aber selbst hier sind Application Server von 4 verschiedenen Herstellen in Verwendung, aber auch viele Anwendungen die nicht im App Server laufen. Das Gesamtmonitoring ist eine eigene selbstgestrickt Anwendung die sie sich auch immer wieder umstricken. Auch werden regelmäßig Stresstests und ähnliches gefahren. Einen Zugriff auf der Quellcode der einzelnen Anwendungen haben sie in der Regel nicht, die liegen bei den entsprechenden Entwicklerteams. Hier geht es eher darum die Probleme zu identifizieren die sich durch das Zusammenspiel der einzelnen Komponenten ergeben und dann an das Entwicklerteam mit möglichst aussagekräftigen Daten weiterzugenen (Stacktraces, CoreDumps, Lastprofile, Profilingdaten etc.)
Das ist allein schon deswegen nötig, da kein Entwickler i.A. nur einen winzigen Ausschnitt des Systems sieht. Den kann er selbst testen, profilen etc. soviel er möchte, aber in der großen Realität und dem Zusammenspiel mit den anderen Teilen ergeben sich dann oft doch Probleme die er allein nicht abdecken kann. Bezüglich deiner Frage zum Wissen der Applikationen kann man sagen das es auch für Operations mehr oder weniger eine Blackbox ist. Sie wissen wie mann es zum fliegen bringt, wo Daten reinkommen und raussollen, und wo die Konfiguationsschrauben liegen.
Ich hoffe damit konnte ich deine Fragen beantworten.

 

[kneitzel]

Gleich mal vorweg, mir geht es hierbei nicht darum Recht zu haben oder irgendjemanden zu überzeugen. Aber falls es dich wirklich interessiert versuche ich es mal grob zu umreissen.

Ja, so sehe ich das auch. Und mich hat es wirklich interessiert, denn da kommen wir aus meiner Sicht doch auch wieder auf einen Nenner meine ich.

So wie Du es beschrieben hast kenne ich es eben auch. Aber damit sind die Haupttools eben im Bereich der Application Server. Nur eben muss man da dann entsprechende Dinge nicht auswerten können (Was eben ohne Sourcen auch nicht wirklich geht.)

Der Standard Ablauf ist dann halt in der Regel so bei uns, dass dann der Kunde / das Ops Team anfragt und dann wird klar gesagt, was geliefert werden soll. Das kommt auch teilweise nicht einmal von uns sondern teilweise kommt das dann auch von Drittherstellern. (IBM ist bei Informix Fragen immer mit im Boot, der Hersteller vom TX Transaktionssystem wird mit hinzu gezogen, wenn es in dem Bereich Probleme gibt ....)

Daher ist es aus meiner Sicht bei den Low Level Dingen halt eher so, dass man diese Tools nicht zwingend im Detail kennen muss, wenn man in diesem Team arbeiten möchte. Da läuft es doch auch nicht anders als bei den Entwicklern: Als Junior musst du erst einmal andere Dinge lernen. Da sind diese Low Level Tools die nur bei Bedarf aufgerufen werden (Core Dumps werden hoffentlich nicht oft vorkommen, Last-Parameter werden hoffentlich automatisch überwacht und visuell dargestellt, ...) sehe ich dann nicht so im Vordergrund. Da sehe ich dann tatsächlich die Application Server, die wichtig sind. Wie werden die generell konfiguriert, wie greifen die wo über welche Methoden aufeinander zu? Und dann auch ganz massiv: Wissen zu den eingesetzten Applikationen. Was bieten die denn alles? Eine Applikation ist ja auch nicht einfach nur ein großer Block sondern ist oft genug auch unterteilt.

Daher ist meine Wertung im Augenblick tatsächlich immer noch so, dass diese Low Level Java Tools eher eine weniger wichtige Rolle spielen.
Aber ich muss gestehen, dass ich in so einem Team bisher nicht gearbeitet habe. Ich kenne das nur einseitig auf der Zusammenarbeit. Daher bin ich hier durchaus an Deiner Erfahrung interessiert und meine Sichtweise mag auch durchaus falsch sein und gewisse Tools spielen eine größere Rolle als ich derzeit glaube ... (Und es kann durchaus sein, dass wir bei uns wichtige Möglichkeiten bisher komplett außen vor gelassen haben und wir da dringenden Nachholbedarf haben. Selbst das möchte ich nicht ausschließen und das macht dieses Thema für mich auch um so interessanter.)

 

[kneitzel]

Und tatsächlich hatte ich gestern Deine Aussage bezüglich

@JustNobody
Und wenn du seine Frage richtig liest steht da ja gerade: "Nur eben nicht als Tool für Sysadmins, sondern eher wie Analyse ich das Verhalten einer JVM ..."

nicht richtig verstanden und den TE falsch verstanden.

Im Grunde wäre sowas wie Java für Sysadmins recht interessant. Nur eben nicht als Tool für Sysadmins, sondern eher wie Analyse ich das Verhalten einer JVM, wo kann ich Stellschrauben anpassen wenn meine Applikation nicht so läuft wie geplant.

Da habe ich mich an der ersten Aussage etwas "aufgehängt" und dann den zweiten Satz nicht richtig gelesen. Denn da schreibt es ja auch klar "meine Applikation". Das hast Du schon in Deiner ersten Antwort sehr gut erkannt, dass ich da offensichtlich etwas missverstanden habe - bei mir dauerte es nur etwas länger wie man deutlich sieht.