Häufige Abstürze des Webinterface

Dennis · Post by **Dennis** » 31 Mar 2006, 12:19

Der Titel ist etwas schlecht gewählt aber folgendes Problem:

Es kommt vor, dass mein Webinterface abschmiert, das heißt es lädt ewig weiter und es kommt kein Ergebnis mehr. Passiert zB bei einer größeren Suche. Ich kann dann erst wieder mit dem Webinterface arbeiten wenn ich die DB neu starte. Die Datenbank läuft aber dennoch normal weiter, wie ich anhand der Logs sehen kann, sie nimmt noch neue Tickets auf und alles, nur die Verbindung zum Webinterface scheint zu hakeln. Hat da jemand Erfahrunf oder vielleicht einen Vorschlag?

lindesbs · Post by **lindesbs** » 31 Mar 2006, 16:52

Be idem ersten Blick in meine Kristallkugel wuerde ich meinen, da stimmt was mit dem Webserve, oder mit dem Perl Programmen nicht.

Kannst du mit einem neuen Browserfenster dich erneut einloggen ?
Laeuft der Webserver noch ? evt. irgendwelche Perl-Leichen ? Was sagt das Log ?

Andre Bauer · Post by **Andre Bauer** » 31 Mar 2006, 17:00

Das kan auch einfach ein Symtom für ne überlastete Datenbank sein.
Installier dir mal mtop und check die laufenden SQL Abfragen.

Dennis · Post by **Dennis** » 03 Apr 2006, 11:15

Ich habe noch was rausgefunden:

Wenn ich in der Suche das Create_by Feld benutze passiert es, bei den anderen suchen konnte ich es noch nicht nachstellen, also habe ich mal die Prozesse der DB abgefragt und siehe da: Dieses Select Statement "blockiert" den SQL-Server:

SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 AND sq.group_id IN (6, 7, 9, 8, 5, 3, 2, 4, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 32, 50) ORDER BY st.create_time_unix DESC LIMIT 5000;

Lasse ich die Gruppen/Queues weg schafft er es, die Dauer ist aber unvernünftig lang:

SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 ORDER BY st.create_time_unix;

+-------+---------+------------------+
| id | tn | create_time_unix |
+-------+---------+------------------+
| 42001 | 1042396 | 1143535123 |
| 42489 | 1042884 | 1143712887 |
| 42523 | 1042918 | 1143719588 |
| 42772 | 1043170 | 1143803491 |
| 42774 | 1043172 | 1143803556 |
+-------+---------+------------------+
5 rows in set (29.82 sec)

Für 5 Zeilen knapp 30 Sekunden.
Ich hoffe es kann mir jemand helfen, denn im Moment steht das OTRS eben 1-2x am Tag und kann nur durch das manuelle töten des SELECT-Prozesses wieder zum Leben erweckt werden.

Gruß Dennis

Andre Bauer · Post by **Andre Bauer** » 03 Apr 2006, 11:51

Wie schon gesagt. Die Datenbank wird wahrscheinlich einfach überlastet sein.
Hättest du mal den Tip mit mtop befolgt, hättest du das wahrscheinlich schon selbst rausgefunden.
Ich hatte das gleiche Problem damals auch und konnte es nur mittels einen separaten Suchservers lösen.

Dennis · Post by **Dennis** » 04 Apr 2006, 10:24

Ich installiers mir mal...trotzdem: Die Last des Servers ist gleich nuch, auch der mySQL Prozess ist nicht sehr "schwer". Da liegt es doch nahe dass die Suchabfrage nicht wirklich optimiert ist, oder?

Edit: Auch mtop brachte mir nicht wirklich Neuigkeiten.Ich sehe nur dass der Prozess ewig dauert, keine erhöhte Last oder ähnliches.

Andre Bauer · Post by **Andre Bauer** » 04 Apr 2006, 10:42

Genau so war es bei mir auch.
Setz ne MySQL Replikation für das Suchen auf und du bist das Problem los.

Dennis · Post by **Dennis** » 04 Apr 2006, 13:04

hm das ist doch irgendwie keine Lösung, vor allem wenn es nachstellbar ist...mal abwarten ob was auf den Bugreport kommt

Andre Bauer · Post by **Andre Bauer** » 04 Apr 2006, 13:06

Hmm. Ich bin nicht überzeugt davon, dass dies ein Bug ist.
Die Option im OTRS gibts ja sicher auch nicht umsonst.

Poste trotzdem mal bitte den Link zu dem Bugreport.

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

Ich glaube nicht, dass sich das mit dieser Problembeschreibung bei jeder beliebigen OTRS Installation nachvollziehen lässt.
Die Datenbank muss dazu schon eine gewisse Größe erreicht haben.
"Created-By Suche bringt Webpanel zum Absturz" ist außerdem ungünstig gewählt, wenns um die Datenbank geht.

Wie groß ist deine Installation (also die MySQL DB)?
Was für Serverhardware (CPU / RAM / HD) nutzt du?

Dennis · Post by **Dennis** » 04 Apr 2006, 13:19

Datenbank ist bissel über 3 GB
Server ist ein HP DL360, 1GB Ram, Xeon 3 Ghz HT und HP Smart Array...

Last ist sozusagen nicht vorhanden:

1:18pm up 19 days 23:51, 1 user, load average: 0.07, 0.04, 0.00

Und mit dem Bugreport: Ich hab das noch nie gemacht, deshalb weiß ich auch nicht wirklich woran ich mich da halten muss.

Andre Bauer · Post by **Andre Bauer** » 04 Apr 2006, 13:46

Bei ner Datenbank von 3 GB erscheint mir das in Ordnung. Immerhin dauert es ne Weile so viel Text zu durchsuchen, wenn so viele Bedingungen dran hängen und über die gesamte Laufzeit des OTRS gesucht wird.

Du kannst das Problem sicher auch umgehen, indem du die Suche zeitlich einschränkst. Bei mir waren 3 Monate immer ein guter Wert. Wenn man dies nicht tut hängt die DB, wie beschrieben ab einer gewissen Größe (ich glaube bei uns ging das so nach ca 1 Jahr los).

Leider wirst du deine Agenten nicht dazu erziehen können, die Suche immer zeitlich einzuschränken. Eine Voreinstellung dafür gibt es ja leider nicht. Die Replikation wird alo die einzige Lösung sein.

Ich bin da auch gerade an nem Howto dran. Kann aber noch ne Weile dauern.