Hallo,
ich suche immer noch dringend nach einer Möglichkeit, meien Perl-Anwendung in hinsicht Speicherverbrauch zu überwachen. Die applikation ist vis Soap::Lite angebunden und es läuft in der Processliste nur der soapserver.pl
5114 root 9 0 962M 343M 46208 S 0.0 68.3 10:54 soapserver.pl
Hier läuft er nun shon ein paar Tage, der Kernel wird wohl gleich zuschlagen.... Ein frisch gestarteter Server sieht so aus: 27192 pummel 14 0 18512 18M 3632 S 0.0 3.5 0:01 soapserver.pl
Wobei mir selber die 18M ein Rätsel sind, aber das wäre ja noch tragbar. Aller x Minuten bekommt der Server ein XML per Soap verpasst, parst das ganze, mach ein Objekt draus und pusselt das in eine DB rein. Geloogt wird intensiv mit log4perl. 90% der Zeit passiert aber gar nix, der Speicherverbrauch wächst aber ständig. Wie bekomme ich raus, was alles schief läuft. Was kann ich tracen debuggen etc ...?
Mit freundlichen Grüßen
Jens Puruckherr
Jens Puruckherr wrote:
Hallo,
Hallo,
ich suche immer noch dringend nach einer Möglichkeit, meien Perl-Anwendung in hinsicht Speicherverbrauch zu überwachen.
[...]
eine DB rein. Geloogt wird intensiv mit log4perl. 90% der Zeit passiert aber gar nix, der Speicherverbrauch wächst aber ständig. Wie bekomme ich raus, was alles schief läuft. Was kann ich tracen debuggen etc ...?
Ich würde ich strace und valgrind empfehlen. Die sind aber beide nicht perl-spezifisch, was dir die Interpretion der Ergebnisse sehr erschweren wird. Ein perl mit Debug-Infos hilft sehr wahrscheinlich auch dabei.
Mit freundlichen Grüßen
Jens Puruckherr
Jens
lug-dd@schlittermann.de writes:
Ich würde ich strace und valgrind empfehlen. Die sind aber beide nicht perl-spezifisch, was dir die Interpretion der Ergebnisse sehr erschweren wird.
Strace habe ich mal angeworfen und schnell wieder aus gemacht. Ich verstehe noch nicht dessen ganze Optionen, aber es scheint mir nur die Systemaufrufe zutracen. Ich habe ja kein Problem mit dem Funktionieren der Anwendung, nur mit dem Speicherhunger. Ein grep nach 'memory' über die man-Page bringt nix, so scheint es wohl nicht das Tool meiner wahl zu sein. Oder jemand hilft mir beim setzen der richtigen Schalter ...
Ein perl mit Debug-Infos hilft sehr wahrscheinlich auch dabei.
Du willst nicht wirklich meine Logs sehen .... ;-) Aber zur Not muss ich noch massig $loggger->debug( system("free -t") ) ; nach jeder Objektinstanzierung, Dateiöffnen, schliessen, beenden, starten, links abbiegen, rechts blinken machen ... Oh Mann ...
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
Wobei mir selber die 18M ein Rätsel sind, aber das wäre ja noch tragbar. Aller x Minuten bekommt der Server ein XML per Soap verpasst, parst das ganze, mach ein Objekt draus und pusselt das in eine DB rein.
Generell an der Anwendung mal bissel "refactoring" zu betreiben, hast Du schon probiert, oder?
Du hast bestimmt ein GarbageCollector-Problem oder verwendest irgendwo XML DOM.
Mehr fällt mir dazu auch nicht ein.
GreetinX Steffen
Hallo,
lug-dd@schlittermann.de writes:
Generell an der Anwendung mal bissel "refactoring" zu betreiben, hast Du schon probiert, oder?
Jo. Ich zerstöre mittlerweile alle möglichen Objekte schon per Hand.
Du hast bestimmt ein GarbageCollector-Problem
Ja, aber welches,wo und wie?
oder verwendest
irgendwo XML DOM.
Ja, genau .... ich lausche..
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
oder verwendest
irgendwo XML DOM.
Ja, genau .... ich lausche..
Bau DOM aus. Nimm was anderes.
Du kennst Dich sicher besser mit dem XML-Kram aus, aber überall lese ich, daß DOM Speicherprobleme macht. Nimm' was anderes.
Ja, wenn das Programm schon geht, ist es schwer, das umzubauen, ich weiß ...
Lies vorher aber noch folgende URL. Hier erzählt Matt Sergeant was zu XML, Speicherlöchern, Utility-Klassen, weak references und man sieht bissel, wie er z.B. zirkuläre Referenzen debugged:
http://www.perl.com/pub/a/2002/08/07/proxyobject.html
GreetinX Steffen
lug-dd@schlittermann.de writes:
Bau DOM aus. Nimm was anderes.
Du kennst Dich sicher besser mit dem XML-Kram aus, aber überall lese ich, daß DOM Speicherprobleme macht. Nimm' was anderes.
DOM hat soweit ich weiss keine Speicherprobleme im vorliegendene Sinne, es benötigt nur mehr Speicher als SAX, da das ganze XML-Objekt im Speicher vorgehalten wird. Es wird aber immer nur ein XML per SOAP an das Programm übergeben. Dann rödelt es und wenn fertig, dann das nächste XML. Meines Verständnisses nach sollte am Ende, wenn ich auch alles schon "geundeft" habe der allozierte Speicher für das nächste XML benutzt werden. Alle XMLs sind kleiner 100KB. Mit top kann man sehr schön sehen, wie der allozierte Speicher in so einem Lauf anwächst, dann gleich bleibt bis zu m nächsten Lauf. Und der alloziert frisch weiter. Möglicherweise wird die Anwendung die der SOAPserver bedient irgendwie nicht richtig beendet, oder der gc greift nicht oder wass weiss ich ...
Ja, wenn das Programm schon geht, ist es schwer, das umzubauen, ich weiß ...
Wenn ich ein XML gegen ein in ihm referenziertes Schema parsen will, bleibt nur der Einsatz eines "grossen" Parsers. Xerces bietet sich da an. Der kann SAX und DOM. Ich war froh das ich die DOM-Kacke halbwegs verstanden habe ... Umbau ist schlecht, weil 1. ich nicht weiss ob es was bringt, 2. die Anwendung bereits produktiv ist. Der Fehler wurde aber erst im Produktivsystem bemerkt, da hier das ganze erstmals über längeren Zeitraum mit vielen Daten laufen musste. Zum Glück gibts dafür einen extra Server und ich kann den ganzen Tag kontrollieren.
Fängt interessant an, ich lese ...
Mit freundlichen Grüßen
Jens Puruckherr
Ich habe da etwas im Code, was villeicht zu diesen zirkulären Refernzen führt, bin mir aber nicht sicher:
my $Shop = Shop->new(); $Shop->init($Artikel->shopid); # Diesen konkrete Shop-Instanz im Artikel merken (Assoziation, Using ??) $Artikel->shop($Shop);
$Artikel ist @ISA = qw(Shop), weil einige Methoden vom Shop benutzt werden, ansonsten ist er das zerparste XML. Zum Schluss mache ich ein undef $Artikel, aber hilft das in diesem Falle?
Mit freundlichen Grüßen
Jens Puruckherr
"Jens Puruckherr" jpuruckherr@cyberport.de writes:
Ich habe da etwas im Code, was villeicht zu diesen zirkulären Refernzen führt, bin mir aber nicht sicher:
my $Shop = Shop->new(); $Shop->init($Artikel->shopid); # Diesen konkrete Shop-Instanz im Artikel merken (Assoziation, Using ??) $Artikel->shop($Shop);
$Artikel ist @ISA = qw(Shop), weil einige Methoden vom Shop benutzt werden, ansonsten ist er das zerparste XML. Zum Schluss mache ich ein undef $Artikel, aber hilft das in diesem Falle?
Wenn shopid oben in $Shop->init() nur ein Zahlenwert ist, dann ist es nicht das Problem. Falls es eine Objektreferenz auf was ist, könnte es das Problem sein.
Die Vererbungsbeziehung ist nicht das Problem.
GreetinX Steffen
Hallo,
Lässt sich irgendwie in das Programm "reingucken", was da noch an Objekten etcx. übrig ist? So kurz vom finalen return? Es muss doch irgendwie rauszubekommen sein, wer sich da im Speicher breitmacht ... Was gibts denn da schönes? Wer weiss es? Ich bin leider in Sachen Debugging absoluter Laie ... wird wohl Zeit, wieder was dazuuzlernen....
Mit freundlichen Grüßen
Jens Puruckherr
On Mon, Dec 01, 2003 at 07:52:01AM +0100, Jens Puruckherr wrote:
Hallo,
Hi Jens,
Lässt sich irgendwie in das Programm "reingucken", was da noch an Objekten etcx. übrig ist? So kurz vom finalen return? Es muss doch irgendwie rauszubekommen sein, wer sich da im Speicher breitmacht ... Was gibts denn da schönes? Wer weiss es?
Also wenn du die Anzahl der Objekte wissen willst könntest du dir ja eine eigene kleine Speicherverwaltung bauen... In C würde man einfach eine Funktion myMalloc() und myFree() implementieren, die das normale malloc() und free() aufrufen aber nebenbei Statistiken führen wann welcher Speicher allokiert wurde und welcher noch nicht freigegeben wurde... Ich weiß nicht in wieweit das in Perl realisierbar ist, da es dort ja eine gc gibt...
Ciao, Tobias
Am Mon, 01.Dec 2003 um 07:52 schrieb Jens Puruckherr:
Hallo,
Lässt sich irgendwie in das Programm "reingucken", was da noch an Objekten etcx. übrig ist? So kurz vom finalen return? Es muss doch irgendwie rauszubekommen sein, wer sich da im Speicher breitmacht ... Was gibts denn da schönes? Wer weiss es? Ich bin leider in Sachen Debugging absoluter Laie ... wird wohl Zeit, wieder was dazuuzlernen....
schau mal nach Data::Dumper, da braucht man aber einen Objektnamen, oder Devel::Symdump ? Würde mich interessieren, ob es brauchbar ist. Viel Erfolg.
Mit freundlichen Grüßen Konrad Riedel
Hallo Konrad,
lug-dd@schlittermann.de writes:
schau mal nach Data::Dumper, da braucht man aber einen Objektnamen,
Der Dumper ist hier wohl ungegeignet, da ich ja erst mal wissen will, ob und was noch so im Speicher rumgeistert.
oder Devel::Symdump ? Würde mich interessieren, ob es brauchbar ist.
Hmm, lt. man-Page wäre das zumindest ein Anfang, allerdings scheint es mir nur vorhandenen Code zu analysieren und alle möglichen Objekte rekursiv aufzudröseln. Hätt ich früher mal gebraucht ;-) Ich wünsche mir was, was mir alles aktuell instanziierte anzeigt.
Viel Erfolg.
Kann ich brauchen .... meine Anwendung wuchs über Nacht auf 136MB. Man kann direkt zugucken, wie mit jedem verarbeiteten XML der Speicherverbrauch wächst :-(
Mit freundlichen Grüßen
Jens Puruckherr IT & Technik --------------------------------------------- cyberport.de GmbH Versandhaus für Technik & Lifestyle
Am Brauhaus 5 01099 DRESDEN Fon: +49 (0)351/ 33 95 -7808 Webseite: http://www.cyberport.de --------------------------------------------
lug-dd@mailman.schlittermann.de
-
Jens Lorenz -
Jens Puruckherr -
Konrad Riedel -
Steffen Schwigon -
Tobias Koenig