Geschwindigkeitseinbruch nach Update von 2.1.7. auf 2.2

McClane · Post by **McClane** » 03 Jul 2007, 23:39

Hallo,

ich setze OTRS auf einer Linux Maschine mit 1GB Ram und einem P4 3.0GHz HT ein.
Apache ist selbst kompliert in der Version 2.2.4 mit einem statischen mod_perl in Version 2.0.3.
Das System ist ein Debian Etch.

Die Geschwindigkeit war mit der Version 2.1.7 ganz ok. Nach dem Update auf Version 2.2 ist die Ausführgeschwindigkeit, vorzugsweise beim auflisten von Tickets, stark eingebrochen.
Z.B. dauert das Anzeigen der Tickets im StatusView jetzt ca. 8 Sekunden. Etwas schneller erscheint die Übersicht der Tickets in der Quere Ansicht. Da sind es aber auch 6 Sekunden.
Die CPU Last geht beim Ausfähren de Scripte auf 100% bis dann die ersten Daten auf dem Schirm erscheinen.
Das Anzeigen der Ticket Infos geht aber dann wieder zügig.
Der mysql Server taucht in top fast gar nicht auf.
In der Datenbank sind gerade mal 1200 Tickets.
Ich bin mal die Performance Tips in der Doku zu mod_perl durchgegangen, aber geholfen hat es nicht spürbar. Zudem habe ich noch an den Apache2 Einstellungen gefeilt, aber da geht es ja mehr um Einstellungen für viele User als um Beschleunigung von Scripten.
Vom Speicher sind noch ca. 400 MB frei, die Swappartition ist nicht benutzt. I/O bedingtes konnte ich auch nicht feststellen. Er braucht scheinbar einfach Zeit um "irgendwas" zu berechnen.
Im Moment weiß ich nicht weiter. Ist das bei anderen nach dem Update auch schon aufgefallen, oder hat noch jemand eine Idee wo das Problem liegen kann?
Achja, in meinem Testsystem ist mir das nicht aufgefallen. Allerdings sind die Maschinen und die Konfiguration nicht die gleiche.

Andre Bauer · Post by **Andre Bauer** » 04 Jul 2007, 10:26

Mach mal bitte einen Bugreport dazu auf. In der Queue View wurde meines Wissens ein Cache Mechanismus integriert, der ja eventuell noch nicht richtig funktioniert...

McClane · Post by **McClane** » 04 Jul 2007, 11:02

Gesagt, getan.

http://bugs.otrs.org/show_bug.cgi?id=2020

McClane · Post by **McClane** » 05 Jul 2007, 09:40

ich habe nun ein backup eingespielt und die daten von hand nachgetragen.
das system läuft nun wieder schnell. die ursache ist aber nach wie vor unbekannt.
ich vermute das falsche oder fehlende datenbank indices schuld waren.

feichhorn · Post by **feichhorn** » 16 Jul 2007, 17:57

McClane wrote: Die Geschwindigkeit war mit der Version 2.1.7 ganz ok. Nach dem Update auf Version 2.2 ist die Ausführgeschwindigkeit, vorzugsweise beim auflisten von Tickets, stark eingebrochen.
Z.B. dauert das Anzeigen der Tickets im StatusView jetzt ca. 8 Sekunden. Etwas schneller erscheint die Übersicht der Tickets in der Quere Ansicht. Da sind es aber auch 6 Sekunden.
Die CPU Last geht beim Ausfähren de Scripte auf 100% bis dann die ersten Daten auf dem Schirm erscheinen.
Das Anzeigen der Ticket Infos geht aber dann wieder zügig.
Der mysql Server taucht in top fast gar nicht auf.

Hier bei mir das gleiche Problem seid dem Update von 2.1.7 auf 2.2.1 ist hier die Perfomance sehr schlecht.
OS: Centos 4.5 in einer VM mit 512 MB RAM

Allerdings sind bei uns noch Fehler im apache error log zu finden:

[Mon Jul 16 17:47:23 2007] [error] [client 192.168.133.49] [Mon Jul 16 17:47:23
2007] index.pl: Use of uninitialized value in hash element at ../..//Kernel/Outp
ut/HTML/TicketMenuTicketWatcher.pm line 49., referer: http://SERVER/otrs
/index.pl?Action=AgentTicketMailbox&Subaction=New

oder

[Mon Jul 16 17:38:29 2007] [error] [client 192.168.133.161] [Mon Jul 16 17:38:29 2007] index.pl: Use of uninitialized value in string comparison (cmp) at /op
t/otrs/bin/cgi-bin/../../Kernel/Output/HTML/Layout.pm line 2147., referer: http://SERVER/otrs/index.pl?Action=Agen ... &QueueID=7

Alle Optimierungen an der Datenbank oder dergleichen haben bisher keinen oder nur sehr wenig geholfen.
Hier scheint es wohl ein Problem zu geben nach dem Update.
Vielleicht hängt es ja mit der neuen Anzeige von Eskalierten Tickets zusammen? Das bei jedem Aufruf der TicketQueue die Zeit neu berechnet wird dieser Tickets und daher die lange Ladezeit kommt.

Aber das ist nur eine Vermutung von mir.

Schonmal danke

Frank Eichhorn

McClane · Post by **McClane** » 16 Jul 2007, 18:42

Nachdem Restore und nochmaligem Update läuft das System ohne Probleme seit einigen Wochen.
In meiner Testumgebung hatte ich den Fehler auch nicht, sonst hätte ich das Update nicht durchgeführt.

ah · Post by ah » 16 Jul 2007, 20:03

feichhorn wrote:Hier bei mir das gleiche Problem seid dem Update von 2.1.7 auf 2.2.1 ist hier die Perfomance sehr schlecht.
OS: Centos 4.5 in einer VM mit 512 MB RAM

Kurze Frage am Rande: bist Du mit den 512 MB RAM zufrieden? Bei mir kommt es alle paar Wochen vor, dass der Speicher einfach komplett voll ist, weil der Apache so viel frisst. Das heißt also im Regelfall einfach mal alle paar Wochen übers Wochenende den Apache abschalten, damit sich das System wieder erholt.
Die Performance ist ansonsten völlig ok, bis auf das Speicherproblem. Wobei ich noch 2.1.7 fahre.

McClane · Post by **McClane** » 17 Jul 2007, 01:08

Ich hab 1GB drin und den Apache auf 5 Prozesse limiert da es sonst ständig vorkommt das die MIME Klasse von Perl Fehler schmeißt und keine Mails mehr versendet.

feichhorn · Post by **feichhorn** » 17 Jul 2007, 11:11

McClane wrote:Nachdem Restore und nochmaligem Update läuft das System ohne Probleme seit einigen Wochen.
In meiner Testumgebung hatte ich den Fehler auch nicht, sonst hätte ich das Update nicht durchgeführt.

Also heisst das für mich alte 2.1.7 wieder installieren und dann die Datenbank neu anlegen? Wenn ja mit dem Backup der 2.2.1 oder dem alten 2.1.7?
Oder Datenbank löschen und ein Restore machen des Systems mit installiertem 2.2.1?

Ein Downgrade würde nur in Frage kommen, wenn die Datenbank erhalten bleibt.

feichhorn · Post by **feichhorn** » 17 Jul 2007, 11:27

Kurze Frage am Rande: bist Du mit den 512 MB RAM zufrieden? Bei mir kommt es alle paar Wochen vor, dass der Speicher einfach komplett voll ist, weil der Apache so viel frisst. Das heißt also im Regelfall einfach mal alle paar Wochen übers Wochenende den Apache abschalten, damit sich das System wieder erholt.
Die Performance ist ansonsten völlig ok, bis auf das Speicherproblem. Wobei ich noch 2.1.7 fahre.

Also bisher mit den 512 MB noch keine Probleme gehabt bisher.
Sind mit 6 Agents am System tätig und bearbeiten damit unsere Support Emails.
Die Performance war mit 2.1.7 auch vollkommen ok. Nur jetzt in der 2.2.1 nicht und bisher habe ich noch keine Verbesserung erreichen können.

Andre Bauer · Post by **Andre Bauer** » 17 Jul 2007, 16:33

Habt Ihr schon mal nen Bugreport dazu eröffnet?

Andre Bauer · Post by **Andre Bauer** » 27 Jul 2007, 11:15

Ist nun laut CVS gefixt.

jojo · Post by **jojo** » 27 Jul 2007, 11:28

in der 2.2.2 enthalten

Hab den Fix gerade auf einer größeren Installation getestet. Vor dem Fix hat der Aufruf von AgentTicketQueue oder AgentTicketStatusView um die 7-8 Sekunden gedauert, nach dem Patch laut Performance log 1s

feichhorn · Post by **feichhorn** » 30 Jul 2007, 11:38

jojo wrote:in der 2.2.2 enthalten

Hab den Fix gerade auf einer größeren Installation getestet. Vor dem Fix hat der Aufruf von AgentTicketQueue oder AgentTicketStatusView um die 7-8 Sekunden gedauert, nach dem Patch laut Performance log 1s

Gibt es schon eine Information wann 2.2.2 erscheint?

Danke für die Info

Frank Eichhorn

ghuerkam · Post by **ghuerkam** » 30 Jul 2007, 18:40

Wahrscheinlich heute:

siehe CHANGES:
2.2.2 (2007/07/30)
- (2007/07/30) Fixed bug# 2015 - Improved handling to allocate customerusers
and services. Now it's possible to define default services.
..

feichhorn · Post by **feichhorn** » 15 Oct 2007, 18:07

Hallo zusammen

Habe nun schon 2.2.3 im Einsatz und die Performance ist leider immer noch nicht zufriedenstellend.

Ergebnis: Oberfläche
Schlüssel Wert Zeit
Request: 1 5 s
Request: 2 4 s
Request: 3 4 s
Request: 4 4 s
Request: 5 4 s
Request: 6 6 s
Request: 7 7 s
Request: 8 4 s
Request: 9 3 s
Request: 10 4 s
Module: AgentTicketQueue 45 s

Ich habe ArticleStorageFS aktiviert und schon die TicketQueue auf DB umgestellt um die Performance zu verbessern.
Wenn ich ein top laufen lasse nimmt die index.pl immer die meiste CPU Last in Anspruch.

Also lautet eigentlich die Frage wie man die "Bremse" aufspürt oder aber die Geschwindigkeit des OTRS weiter verbessern kann.

Zum Einsatz kommt:

OS: CentOS 4.5
Apache 2.0.52
ModPerl 1.99
Perl: v5.8.5
MySQL: 4.1.20

Wenn noch weitere Daten benötigt werden, liefere ich diese gerne.

Mit freundlichen Grüßen

Frank Eichhorn

Andre Bauer · Post by **Andre Bauer** » 15 Oct 2007, 18:57

Wie ist denn dein Rechner ausgestattet?

feichhorn · Post by **feichhorn** » 22 Oct 2007, 11:48

Hallo

Im Moment ist das OTRS in einer VM auf VMWare Server mit 512 MB RAM.
Das ganze dann auf einem Dual Xeon Dell Server 1750.

Hatte vorher eine Installation auf eigener Hardware dort aber auch 512MB RAM.

Die Auslastung des VM Servers ist nur bei 20-50% laut unserer Überwachung.

Frank Eichhorn