Schlagwort: debugging

Kategorien
Allgemein

Mit angezogener Handbremse

Seit einigen Wochen hatten wir ein Problem mit unserem Softwareloadbalancer, der auf einem unserer Tomcatserver läuft. Dachten wir.

Die durchschnittliche Last (loadavg) auf dem Server ging in relativ regelmäßigen zweistündlichen Abständen auf über zehn. Da die Lastprobleme mit dem Lastverteiler  umzogen hatten wir den nebenher laufenden Tomcat relativ früh als Verursacher der Probleme ausgeschlossen.

Ein Irrtum.

Wegen eines anderen Problemes haben wir während einer solchen hochlast Phase den Tomcat mittels

kill -quit $TOMCAT_PID

mehrere Threaddumps schreiben lassen. Bei der Analyse dieser Dumps fiel uns dann auf, dass ein übervorsichtiger Programmierer eine Garbage Collection bei jedem Aufruf seines Servlets veranlasste.

Glücklicherweise kann mittels Parameter der JavaVM das Beachten dieser Aufforderung ausgetrieben werden. Seit wir die Option -XX:+DisableExplicitGC für die Tomcat JavaVM nutzen, sind alle Lastprobleme verschwunden. Ebenso zeigte sich, dass die Anzahl der möglichen Anfragen an das Servlet von etwa vier Anfragen pro Sekunde auf etwa 200 Anfragen pro Sekunde hochschnellten.

Und netterweise sind in dem Servlet auch die Aufrufe von System.gc() verschwunden.

Kategorien
Allgemein

Super Fehlermeldungen

Gut formulierte Fehlermeldungen können einem Administrator viel Zeit ersparen. Schlechte kosten im besten Fall nur Nerven.

In meinem letzten Fall hat es mich insgesamt mehrere Tage gekostet. Ganz konkret ging es um den Imap Server von Cyrus. Um dem erhöhten Mailaufkommen beizukommen wollen wir unseren derzeitigen Mailserver (auch von Cyrus) durch eine Cluster-Installation ersetzen. Der letzte Test bestand dann darin, dass der MTA eine Mail über einen Lmtp-Proxy an den eigentlichen Speicherort der Mail weiterreicht.

Das hat er in meiner Testinstallation auch wunderbar gemacht.

In der Produktionsinstallation weigerte er sich mit einer Meldung, dass es keine „worthy mechs“ gäbe. Also keine Mechanismen zur Authentisierung/Authorisierung, mit denen der Proxy mit dem Backend sprechen wollte.

Goggle bietet hier schnell viele Treffer an, die alle in die Richtung TLS Verschlüsselung gehen. Nur die funktionierte bei meiner Installation.

Des Rätsels Lösung lag darin, dass für den Namen des Backends kein Passwort in der Konfiguration des Frontends hinterlegt war.

Tolle Fehlermeldung.

Kategorien
Allgemein

Perl ausprobieren

Immer mal wieder frage ich mich, was ein einfacher Perl-Ausdruck denn nun wirklich macht. Da kommt der eingebaute Debugger genau richtig.

Für einfache Ausdrucke und Versuche ist es natürlich am einfachsten einen Perl-Einzeiler zu benutzen. Also

perl -e 'print "Hallo Weltn"'

Für Ausdrucke, die aber auf Variablen zur Laufzeit angewiesen ist, kann es recht müßig sein die History der Shell zu nutzen, oder eine Datei zu öffnen und dort  zu experimentieren.

Debugger to the rescue

Da bietet sich dann an den Debugger zu benutzen. Aber ich will ja eigentlich keine Datei entwanzen. Das Programm für den Debugger muss aber auch gar nicht gross sein. Eine einfache 0 tut es da auch. Mit perl -d -e 0 gelangt man mit dem folgenden Ausdruck in seine persönliche Perl Spielwiese:

user@rechner:~$ perl -d -e 0
Loading DB routines from perl5db.pl version 1.28
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(-e:1):    0
  DB<1> $a="hallo"

  DB<2> print "$a weltn"
hallo welt

Wie man sieht, kann man im Debugger Variablen setzen und auf diese im nächsten Ausdruck zugreifen.

Mit dem üblichen Debugger Befehl x – Untersuche (eXamine) diesen Ausdruck/diese Variable – können wunderbar auch geschachtelte Datenstruckturen anschaulich dargestellt werden.

  DB<3> @a=qw(hallo welt)

  DB<4> x @a
0  'hallo'
1  'welt'
  DB<5> x @a
0  ARRAY(0x8404d64)
   0  'hallo'
   1  'welt'
  DB<6>

Macht man einen Fehler, so gibt der Debugger eine Fehlermeldung aus und man hat wieder einen neuen Versuch.

  DB<6> $a[a)
syntax error at (eval 11)[/usr/share/perl/5.8/perl5db.pl:628] line 2, near "a)"
Missing right curly or square bracket at (eval 11)[/usr/share/perl/5.8/perl5db.pl:628] line 4, at end of line
Kategorien
Allgemein

Hohe Hürden für wahre Helden

Ich kann die armen PHP Programmierer nur bedauern. Das schreiben von einfachen Anwendungen mit PHP soll ja recht einfach sein, aber wehe es gibt einen Fehler. Das Debuggen von PHP Programmen ist nicht einfach.

Aus dem Grunde werden wohl die meisten PHP Anwender das Debuggen per echo oder var_dump anwenden. Wenn das aber nicht mehr ausreicht, so muss doch ein echter Debugger her. Da gibt es mehrere in der OpenSource Welt.

Ausprobiert habe ich XDebug und DBG.

DBG war als erstes an der Reihe. Nachdem ich das Modul nach Anleitung kompiliert und installiert hatte, dauerte es auch nur noch einen halben Tag, bis ich mich mit PHPEclipse mit dem Debugging anfangen konnte. DBG kann sich pro Anfrage per Parameter auf einen anderen entfernten Debugger einlassen. Was von Vorteil ist, wenn mehrere Entwickler mit einem Webserver arbeiten. Leider habe ich es nicht hinbekommen, dass auch jede Anfrage an den Debugger weitergeleitet wurde. Alles in allem, keine schöne Erfahrung.

Danach habe ich noch XDebug ausprobiert, da es von der pdt Erweiterung des Eclipse-Projektes genutzt werden kann. Mit der von DBG gewonnenen Erfahrung bin ich schon viel schneller zum Debuggen gekommen. Aber anscheinend geht XDebug davon aus, das immer nur ein Entwickler debuggen will. Denn das PHP Modul verbindet sich immer mit einem bei Apache Start voreingestellten Host und Port. Dafür zeigte sich der Debugger etwas stabiler als DBG. Als nettes Beiwerk verändert XDebug die Ausgabe von var_dump und den Fehlermeldungen von PHP. Auch ist ein einfacher Profiler einschaltbar, dessen Ergebnisse mit kcachegrind auswertbar sind. (DBG soll auch einen Profiler enthalten, aber die Doku ist quasi nicht vorhanden.)

Alles in allem: Arme PHP Entwickler.