JAX 08: Troubleshooter oder Troublemaker - Der Entwickler und seine Feuerwehr

von Thomas Bahn,
assono GmbH, Standort Kiel,



Rainer Jung
Troubleshooter oder Troublemaker ? Der Entwickler und seine Feuerwehr

  • Aufwärmrunde
  • Typische Problemsituationen
  • Beobachtbarkeit und Beobachtung
  • Zusammenfassung

Abstrakte Problembeschreibung

Performance-Probleme

  • Anwendung ist zu langsam (einzelne Vorfälle)
  • es bilden sich Staus (in Folge ist die Anwendung nicht mehr erreichbar)

    Stabilitätsprobleme
  • Anwendung reagiert nicht mehr

    Nicht betrachtet: Probleme der fachlichen Korrektheit

    Mögliche Rahmenbedingungen
  • Probleme treten sporadisch auf, kein Muster bekannt: Reproduktionschancen schlecht
  • Probleme treten zu Hochlastzeiten auf: Reproduktionschancen besser
  • Probleme treten nach einiger Zeit auf: Reproduktionschancen unklar

    Ausgangslage
    a) schlechte Beobachtbarkeit
  • Umkehrschluss: Probleme mit guter Beobachtbarkeit lösch die Kunden alleine
    b) häufig Überlagerung mehrer Probleme
    a) + b) => Es ist extrem wichtig, echte Beobachtungen von vermuteten Ursachen zu unterscheiden


    Typ 1: Locking als Problemursache

    Locking/Synchronisation ist nicht böse, sondern absolut notwendig!
    aber:
  • Die Lock-Belegung darf nicht zu lange dauern
  • Die Akquisitionsrate darf nicht zu hoch sein
  • Genauer: das Produkt aus beiden muss deutlich kleiner als 1 sein
    Beispiele
  • Mittlere Belegung: 10 µs, 2.000 Locks/Sekunde -> ok
  • Mittlere Belegung: 5000µs, 4 Locks/Sekunde -> ok


    Mögliche Auswirkungen von Lock-Problemen

    Sonderfall Deadlock

    Lock-Contention
  • Quasi-Serialisierung eines Teils der Anwendung
  • Performance-Engpass auf Multi-CPU/-Cores-Hardware
  • Das Problem tritt nicht-linear auf

    Thread-Starvation
  • Vor allem bei stark genutzten Locks
  • Einzelne Threads bekommen den Lock nicht oder zu selten
  • Es gibt Locks mit Fairness, aber: Fairness bedeutet komplexer Code (langsam), kann konträr zum OS-Scheduler sein (langsam), erhöht also in der Regel die Log-Contention


    Locking-Regeln

    Vermeidung Lock-Contention
  • kleine komplexen Operationen während ein Lock gehalten wird
  • weniger Informationen sharen, mehr echte Unabhängigkeit
  • Beschäftigen Sie sich mit den Möglichkeiten von JSR-166: Concurrency Utilities
    Häufig Probleme auch in Hilfsbibliotheken

    Vermeidung von Deadlocks
  • Total Lock Ordering
  • In der Regel aber kein allgemeines Rezept, sondern fallbezogene Lösung


    Wie finden wir Lock-Probleme?
  • Thread-Dumps


    Typ 2: Sizing

    Viele Anwendungen haben Komponenten, die konfigurierbare Größen haben

    Bei Produktionsstart häufigstes Sizing: Default
    Manchmal auch; pi mal Daumen, dann aber nmicht konsistent

    Verständlich ist
  • schlechtes Sizing wegen mangelnder Vorerfahrung
  • schlechte Dokumentation
    aber nicht:
  • fehlende Beobachtung

    Zusatznutzen der Produktionsbeobachtung
  • entstehende Erfahrung zu sinnvollem Sizing

    Hier ist ein Zusammenspiel von Entwicklung und Betrieb nötig


    Typ 3: Remote-Probleme

    Performance-Probleme bei verteilten Systemen

    Beobachtbarkeit von zentraler Bedeutung
    Hier reicht jedoch ein Thread-Dump nicht aus
    Bei Problemanalyse zwischen grob-granularen Komponenten ist Logging sehr hilfreich
  • insbesondere bei Remote Calls und Wechsel von Technologie und/oder Zuständigkeit


    Typ 4: Ressourcen-Engpass

    Anwendungen nutzen Hardware-Ressourcen
  • CPU, Netz, Platte

    Beobachtung und Analyse der meisten Engpässe bei HW-Ressourcen ist recht gut verstanden

Beobachtung und Analyse von Engpässen
im Bereich Memory ist weniger gut verstanden

  • mehrere Schichten Speicherverwaltung
  • virtuelles Memory

    Java-Memory und Garbage Collector
  • viele Konfigurationsmöglichkeiten
  • aber wenig gute Dokumentation (korrekt und umfassend)
  • Beobachtbarkeit: ganz schlecht
  • GC-Logging vor Java 6: sehr schlecht, ab 6 Update 4 wenigstens mit Zeitstempel

    Ressourcen-Virtualisierung
  • auch bei den gut verstandenen Ressourcen wird es durch Virtualisierung zu Problemen kommen


    Thread-Dumps

    Momentaufnahme der Code-Ausführung in der JVM

    Liste aller Threads
  • mit Name und ID, sowie Zusatnd (etwa runnable)
  • mit kompletten Funktionsstack der Java-Methoden
  • mit Informatioen bzgl. des Wartens auf Locks
  • mit Ausgabe, ob Deadlock vorliegt

    Momentaufnahme
  • meist muss man mehrere Aufnahmen machen, um Zufallsbeobachtungen auszuschließen

    Thread-Dumps sind ein JVM-Features und gehen sehr schnell, auch in Produktion ok, auch regelmässig (z. B. stündlich)

    Dump landet im STDOUT, sollte also mit Startskript aufgefangen werden - oder Service-Wrapper verwenden


    Tipp: Tanukisoft Service Wrapper für Windows


    Dump-Auswertung
  • meist sehen wir uns zunächst nur die obersten 5-10 Methoden des Stacks an
  • Threads gruppieren, deren top-n Methoden-Stack gleich ist
  • Auswerteskript!
  • Hypothesen im vollen Dump überprüfen

    Phänomene, die sich meist gut durch Thread-Dumps verstehen lassen:
  • Anwendung ist langsam, obwohl die CPU-Auslastung gering ist
  • CPU-Auslastung ist zu hoch
  • Anwendung reagiert nicht mehr

    Thred-Dumps: Vorschläge
  • auch mal in Produktion machen, wenn es noch keine Probleme gibt
  • versuchen sie, Dumps zu verstehen
  • nicht von Größe abschrecken lassen
  • dem Betrieb erklären, wozu das gut ist


    Logging
    Performance und Erfolgsprotokolierung an den Schnittstellen
    Vergeben Sie eindeutige Vorgangs-IDs


    JMX


    Monitoring
  • Störungen feststellen und melden
  • kontinuierliche Messung von Betriebszuständen


    Zusammfassung

    Die häufgstien Produktionsprobleme sind
  • Performance-Probleme
  • Stabilitätsprobleme

    Wir brauchen auch Beobachtungen aus "guten" Zeiten

    Beobachten mittels
  • Thread-Dumps
  • Logging
  • Monitoring

    Lasttests von Produktionsaufnahme sinnvoll

    Probleme werfen ihre Schatten voraus, also vorher hinsehen

    Brücke zwischen Entwicklung und Betrieb bauen
Veranstaltung Fachbeitrag JavaScript Sonstiges

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen oder möchten eine Demo anfordern?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

Wir verwenden Ihre Daten, um Sie einmalig per E-Mail zu kontaktieren. Wir geben Ihre Daten nicht an Dritte weiter. Siehe: Datenschutzhinweise
assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Techn. Hotline: +49 4307 900 403
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de