Suchst Du noch Schuldige oder löst Du schon Probleme?

oder: Schwarzer Peter spielen ist keine Lösung

Es brennt. Die wichtigste Java-Applikation der Firma steht oder ist unerträglich langsam; das Management drängt auf eine schnelle Lösung. Da muss die Feuerwehr her, gerne in Gestalt externer Troubleshooter. Diese können unbelastet an das Problem herangehen und bringen oft auch noch andere wertvolle Expertise und Werkzeuge mit.

Als Beratungsdienstleister ist uns bei codecentric diese Situation wohl bekannt. Neben der Erfahrung bringen wir dazu die nötigen Tools mit, sofern sie nicht schon vorhanden sind: Produktionsmonitore wie z.B. AppDynamics , Profiler wie z.B. JProfiler und andere Helferlein wie z.B. Eclipse Memory Analyzer . Wichtiger ist aber, dass wir als Externe einen unverstellten Blick auf die Systeme werfen können und auch jede Menge Fragen stellen dürfen.

Fragen, die sich diejenigen, die die Applikation schon lange kennen, aus verschiedenen Gründen nicht mehr stellen oder nie gestellt haben. Gemeinsam mit dem Kunden finden wir dann die Problemursache in der Regel recht schnell und dann passiert manchmal etwas Überraschendes. Nämlich nichts.

Performance Troubleshooting – ein symptomatisches Beispiel

Ein Vorteil von Java Anwendungen ist das automatische Speichermanagement; allerdings gibt es eine Vielzahl von Problemen die damit einher gehen können. Nehmen wir z.B. eine Rich Client Applikation, welche mit einem Server stateless kommuniziert und sehr viele Daten verarbeitet. Diese werden natürlich aus der Datenbank geholt, der Einfachheit halber über Hibernate. Es werden dabei auf dem Server eine Unmenge von kleinen Objekten erzeugt, die auch gleich wieder verworfen werden (Memory Thrashing). Das läßt sich mit Hilfe eines Produktionsmonitors schön beobachten (siehe die 3 exemplarischen Grafiken). So ist die kritische Komponente auch gleich erkannt.

Hibernate in Action

Alle SQL Calls der Transaktion

Speicherauslastung und GC

Zusammen mit Verlaufsgraphen für den Speicherverbrauch aus dem Produktionssystem kann man also visuell nachweisen, dass Hibernate kurzfristig viel Speicher braucht für die einzelnen Objekte. Damit natürlich auch viel CPU für Garbage Collections und  jede Menge SQL Statements.

Sehr gut: Wir haben das Performance Bottleneck gefunden. Und wissen auch, dass die Skalierbarkeit natürliche Grenzen hat. Man kann sich das so vorstellen wie einen Stall, der ursprünglich für Hühner konzipiert wurde, nun aber Vögel im Strauß-Format darin untergebracht werden sollen.

Sicherlich kann man jetzt die Käfige vergrößern und die Abfallentsorgung optimieren, aber es werden nicht dieselbe Anzahl Straußvögel wie ehemals Hühner hineinpassen. Um das zu erreichen, müssten die Strauße kleiner und leichter oder der Stall komplett umgebaut werden. Mit einer einfachen Konfigurationsänderung ist es hier nicht getan.
Klingt logisch? Ja! Nur ist nicht jeder ein Vulkanier .

Problem gefunden – Maßnahmen ergriffen

Was wir oft sehen sind folgende Maßnahmen (in dieser Reihenfolge):

• Mehr Speicher geben (bei 32-Bit JVMs begrenzte Möglichkeiten)
• Regelmäßig neu starten (cron job)
• Noch mehr Speicher geben
• Noch öfter neu starten (einmal stündlich scheint aber störend für die Anwender zu sein)
• Ein APM Werkzeug zur Überwachung einsetzen und gezielt neu starten
• Spezialisten zum Tuning holen – Gerne die beteiligten Softwarehersteller, die dann nachweisen, dass es nicht an ihrer Software liegt und man nichts mehr tunen kann
• Schimpfen, Messen, Schimpfen
• …

Was fällt auf? Genau: Das eigentlich zugrundeliegende Problem wurde nicht wirklich angegangen, der Root Cause nicht beseitigt.

Problem wird nur geschickt umschifft, aber warum ist das so?

Die Gründe dafür sind mannigfaltig, weshalb die Liste auch nur einen Auszug darstellt:

• Die Anwendung wurde von externen Kräften entwickelt und wenig bis gar nicht dokumentiert, aber strikt nach Vorgabe entwickelt und abgenommen – kann also nicht das Problem sein
• Die verschiedenen Abteilungen (Entwicklung, Test, Operating) sind streng voneinander getrennt und die Übergabepunkte genau definiert – es findet keine Kommunikation statt (siehe auch Agile Worst Practices – 4 )
• Frameworks wurden nach Fachlichkeit benutzt und ohne Berücksichtigung der Performance-Aspekte verwendet. Das funktioniert prima am Entwicklerarbeitsplatz, aber oftmals nicht unter Produktionslast
• Open Source Komponenten wurden erweitert, am besten von Externen, so dass keine der googlebaren Hilfestellungen wirklich weiterhilft – hier ist viel Aufwand und Sachverstand notwendig
• Es handelt sich um eine komplette Eigenentwicklung und der verantwortliche Entwickler hat das Unternehmen verlassen – die Dokumentation besteht aus TODO Tags
• Die Architektur wurde mit Fachleuten sehr lange entwickelt und optimiert und kann nicht falsch sein – da wurde ein Hühnerstall entwickelt, nach Erfolg als Blaupause gesetzt und jetzt wird aber ein Straußenstall gebraucht

Neben den vorangegangenen Gründen gibt es noch eine Menge weiterer und auch Kombinationen daraus.

Was tun? Alternative zum traditionellen Blame Game

Ein Monitoringtool hilft, beschafft aber nur die Rohdaten. Erst der Mensch kann die richtigen Schlüsse ziehen. Die Überwachungs- und Profilingtools mögen noch so gut sein, aber hier hilft meiner Ansicht nach nur Kommunikation und Offenheit. Der operative Betrieb und das Business (die Fachabteilung) haben das Problem, aber beseitigen können es nur die Techniker (Entwickler, Architekten, etc.) – hier muss also ein Dialog entstehen. Dieser wird oft durch Altlasten oder auch politische Entscheidungen verhindert.

Stattdessen wird in langwierigen Krisenmeetings versucht DEN Schuldigen zu finden, der die Verantwortung für das Problem übernehmen muss (Blame Game, Schwarzer Peter). Man konzentriert sich also auf die Personen oder die Abteilung, nicht auf die Ursache des Problems. Das ist absolut kontraproduktiv. Die Beteiligten (Entwickler, Architekten, Software Hersteller, SysAdmins, Fachbereich, etc.) werden hier meist gezwungen sich zu verteidigen und zu erklären, warum der Fehler NICHT in ihrem Bereich sein kann, bzw. dass die gefundenen Problemursachen aus Sachzwängen entstanden sind, an denen man nichts ändern kann. Das löst aber das Problem nicht.

Einen objektiven Dialog können die gefundenen Messwerte und Tatsachen als Katalysator  ermöglichen. Das hängt auch sehr vom Fingerspitzengefühl des Moderators einer solchen Krisensitzung ab. Als externer Berater hat man die Möglichkeit unbelastet von der Vorgeschichte die kritischen Punkte als solche anzusprechen und die entscheidende Frage zu stellen: Wer kann das eine Problem am besten lösen, wer das andere? Was können die einzelnen Abteilungen dazu beitragen? Wenn sich dabei heraustellt, dass eine Lösung, die das Problem wirklich beseitigt viel Zeit und Geld kostet, kann eine andere Diskussion in Gang kommen. Aber als Ergebnis hat man dann einen Grund für die Probleme und die Gewissheit, dass man damit leben oder Geld in die Hand nehmen muss. Eine Entscheidung, die letztlich das Management für die Firma zu treffen hat.