Framwork debuggen

[dg1rtf]

Moin,

Ich versuche gerade verzweifelt otrs von 3.2 nach 3.3 zu bringen. Dazu muss muss ich dann auch noch das System von CentOS 5 nach 6 wechseln. Funktioniert auch alles, ausser ITSM.
Solange ich beim 3.2 Framework auf dem neuen System bleibe, ist die Welt auf dem neuen System in Ordnung.
Sobald ich nach 3.3 update und das ITSM nachziehe (egal welche Version) blockiert der apache thread mit 100% Last sobald ich die Uebersicht der CMDB Elemente mir anschauen will. Im strace auf diesem Thread kann ich nichts erkennen. Beim tcpdump der Datenbank-Verbindung faellt auf, dass Queries kommen, aber in sehr grossen Abstaenden. Sieht aus, als ob irgendwo ein Timeout abgewartet wird.
Pakete neuinstallieren, CacheClean, ... bringt alles nichts.
Ich gehe mal davon aus, dass es an meiner Installation liegt, bin aber mittlerweile voellig ratlos, wie ich aus der Nummer rauskomme. Hat jemand eine Idee, wie ich auf einem CentOS 6 das Framework debuggen kann um wenigstens die Stelle zu finden, wo es haengt?

Danke
Thomas

[wurzel]

Hi,

in den Logfiles steht nix?

Da würd ich otrs Support mal fragen. Ich wüsste nicht, wie das geht, ausser logfiles lesen.

Flo

[BIG_jan]

Das liegt an der neuen 3.3er Version der CMDB.
Dort kann man wenn man will, für jede klasse die Angezeigten Spalten individuell einstellen. Somit auch Werte anzeigen alssen, die nicht in der tabelle configitem oder configitem_version stehen, sondern tief versteckt in der xml_storage.
In der 3.2 hat die CMDB nur die paar Werte aus der configitem_version und configitem geladen (pro angezeigtem Item).
Nun in der 3.3 lädt er pro angezeigtem Item alle Werrte, die zu der Klasse gehören. Sollten nun (bsp in der Computer-Klasse) mehrere IP-Adressen eintragbar sein und vielleicht noch ein paar verschachtelte Werte, lädt er ALLE diese Werte, auch wenn sie nicht angezeigt werden. (Aber sie könnten ja angezeigt werden, eventuell).

Durch diese extreme Mengenvergrößerung ist die CMDB teilweise unbrauchbar langsam geworden. Die genauen Dateien lann ich dir aus dem Kopf jetzt leider auch nicht sagen, aber vermutlich output/hteml/layoutitsm.pm mal als Suchstart anschauen.

Ich hoffe due verstehst, was ich sagen wollte. Es liegt nicht an dir, sondern an OTRS. Ich hoffe sie sind da irgendwie dran

[reneeb]

Es liegt an den _XMLData2Hash-Funktionen. "grep"pe mal danach. Die machen hunderte von SQL-Queries wenn Du viele Attribute und viele Config Items hast. Ich habe für einen Kunden für eine Erweiterung etwas wesentlich schnelleres gemacht, werde aber vor Ende Juni nicht genug Muse haben das unbezahlt in einen PullRequest an die xxx umzuwandeln. Wer Lust hat, dem kann ich die Klasse gerne schicken. Die müsste noch dokumentiert, ausführlich getestet und dann im Code verwendet werden.