MySQLd verlangsamt OTRS

Dennis · Post by **Dennis** » 07 Mar 2007, 16:17

Hallo,

also folgendes Problem:

Mein Suchserver habe ich bereits ausgelagert. Trotzdem, wenn ich jetzt auf "Suche" klicke dauert es relativ lange (10-20 Sekunden) bis tatsächlich die Suchmaske erscheint. Auf dem Hauptserver geht dabei die DB-Last auf 100% bis dann die Maske geladen ist.

Hat jemand eine Idee? Datenbank ist relativ groß, ~13GB

Andre Bauer · Post by **Andre Bauer** » 07 Mar 2007, 16:36

Die Suchmaske selbst ist bei uns schnell da. Da dort nichts gesucht wird, sondern eigentlich nur kurz connected werden müsste, sollte das bei Dir eigentlich auch schnell gehen.

Ne Volltextsuche über die ganze DB zwingt unsren Suchserver aber auch schon mal in die Knie.

Wie lange dauert den eine Suche bei Dir?
Ist das dann im Verhältnis auch noch mal länger?

Dennis · Post by **Dennis** » 07 Mar 2007, 17:24

Nein die Suche ist wieder flott...

Andre Bauer · Post by **Andre Bauer** » 07 Mar 2007, 17:55

Hast du für den Suchserver in der Sysconfig ne Domain oder ne IP angegeben?
Eventuell ists ja ein DNS Problem?

Dennis · Post by **Dennis** » 07 Mar 2007, 18:11

Eher nicht, bei Klick auf "Suche" geht ja auf dem Hauptserver die Last hoch.
Er geht dann folgende Abfragen durch (in etwa):

| 176339 | otrs2 | localhost | otrs2 | Query | 0 | Copying to tmp table | SELECT distinct(freetext2) FROM ticket |
| 176339 | otrs2 | localhost | otrs2 | Query | 0 | Copying to tmp table | SELECT distinct(freekey3) FROM ticket |
etc.etc.

Wenn er damit fertig ist kommt die Suchmaske. Was mich wundert ist dass er dafür solange braucht, er scheint ja nur die möglichen Freitextfelder und Freitextinhalte aus der DB zu ziehen.

In meinem Fall wären das 5 Freitextfelder mit insgesamt vielleicht 80 Auswahlmöglichkeiten.

Die Redundanz-DB wurde mit IP angeben.

Vielleicht kann man ja die lokale MySQL DB noch optimieren?

EDIT: ich habe mal spasshalber die RedundanzDB rausgenommen, trotzdem die selbe lange Wartezeit

Dennis · Post by **Dennis** » 09 Mar 2007, 18:14

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

Ich hab nen Bugreport erstellt.

Andre Bauer · Post by **Andre Bauer** » 09 Mar 2007, 18:40

Wie groß ist die Article Tabelle eigentlich?
Die 13 GB Datenbankgröße kommen doch sicher von den Mail Anhängen, oder?

Dennis · Post by **Dennis** » 12 Mar 2007, 10:49

article = 165 MB
article_attachment = 4,8 GB
article_plain = 6,6 GB
ticket_history = 3,1 GB

Gesamt bin ich inzwischen bei 14,6 GB

Andre Bauer · Post by **Andre Bauer** » 12 Mar 2007, 11:17

Hmm. Dann müsste das eigentlich sehr schnell gehen, wenn er auf die Article Tabelle zugreift.
Die ist bei mir ja wesentlich größer und es geht fix.
Insgesamt komm ich aber besser weg, da ich alles im FS speichere.

article = 1,9 GB (697.158 Einträge)
article_attachment = 0 GB
article_plain =0 GB
ticket_history = 325 MB (2.415.838 Einträge)
Im FS liegen dann noch mal 40 GB Plain Mails und Anhänge.

Was mich wundert ist deine Ticket History.
Die sollte meiner Logik nach nicht größer sein als meine, wenn die Article Tabelle kleiner ist?

Hast Du schon mal versucht dem mysqld etwas mehr Speicher/Cache über die my.cnf zu geben?

Eventuell liegts auch an der Hardware?
Wie verhält sich das System die sonst bei der Arbeit?
Bringt die Festplatte noch genug Durchsatz?

Dennis · Post by **Dennis** » 12 Mar 2007, 11:25

The case you described is probably a known
issue. When displaying the search result, a lot of lookups are done to get the
data for each ticket. Most costly seem to be customer data (name email etc). If
you take those out of the dtl-files for the pages you'd like to speed up you
may see drastic improvements.

We're trying to address this in a more general way (caching) in one of the
upcoming releases...

hth,
Your ((otrs)) Team

Also abwarten...

Dennis · Post by **Dennis** » 12 Mar 2007, 11:29

Das mit der Ticket_history lag meines Erachtens an fehlerhaften Generic Jobs...da ist der Wachstum auch lang nicht mehr so groß.

Wobei mich das mit den Attachments ins FS doch interessieren würde. Ich hatte das bei der 1.3er mal versucht und da gings nicht.
Werd ich mal versuchen die Attachments ins FS zu speichern

Und zum Verhalten des Servers: Da ist alles in Ordnung, Plattendurchsatz etc macht keine Probleme.

Andre Bauer · Post by **Andre Bauer** » 12 Mar 2007, 11:46

Das kannst du ja im Betrieb problemlos umstellen.
Um die alten Tickets aus der DB in das FS zu bekommen, hab ich mal nen Generic Agent auf der Mailingliste (eventuell auch auf der englischen) gesehen.
Habe selbigen aber nie selbst getestet.

Dennis · Post by **Dennis** » 12 Mar 2007, 11:52

Wieder ein Schreibrechtproblem wenn ich umstell, versteh ich nicht ganz. Da muss ich mal genauer untersuchen. An den Generic Job erinner ich mich auch noch.

BTW: Wir werden OT

Andre Bauer · Post by **Andre Bauer** » 12 Mar 2007, 11:57

Hmm. Wahrscheinlich musst du einfach das Setpermissions Script nochmal ausführen.

Bei mir wäre das dann:

Code: Select all

/opt/otrs/bin/SetPermissions.sh /opt/otrs otrs www-data www-data www-data

Unter Suse nennt sich der Apacheuser imho anders. Müsstest du also noch anpassen. Danach sollte es auf jeden Fall funktionieren.

Dennis · Post by **Dennis** » 08 Nov 2007, 11:44

So um hier mal zum Thema zurückzukommen:

Ich habe für das Problem einen kleinen Workaround. Zuerst habe ich das ganze über den SQL Query Cache versucht, was aber leider nicht sehr erfolgreich war. Darum gehe ich jetzt so vor, dass ich eine neue Tabelle erstelle in die einmal täglich die DISTINCT Abfragen eingefügt werden. Die Suchmaske frägt dann direkt von dieser Tabelle ab.

Das SQL Script zum erstellen der neuen Tabelle (habe ich dann in cron.daily eingebunden):

Code: Select all

### SQL Generieren der Freitext/Key Tabelle
#
#

drop table if exists freekeytext;

create table freekeytext (
freekey1	varchar(80),
freetext1	varchar(150),
freekey2	varchar(80),
freetext2	varchar(150),
freekey3	varchar(80),
freetext3	varchar(150),
freekey4	varchar(80),
freetext4	varchar(150),
freekey5	varchar(80),
freetext5	varchar(150),
freekey6	varchar(80),
freetext6	varchar(150),
freekey7	varchar(80),
freetext7	varchar(150),
freekey8	varchar(80),
freetext8	varchar(150),
freekey9	varchar(80),
freetext9	varchar(150),
freekey10	varchar(80),
freetext10	varchar(150),
freekey11	varchar(80),
freetext11	varchar(150),
freekey12	varchar(80),
freetext12	varchar(150),
freekey13	varchar(80),
freetext13	varchar(150),
freekey14	varchar(80),
freetext14	varchar(150),
freekey15	varchar(80),
freetext15	varchar(150),
freekey16	varchar(80),
freetext16	varchar(150)
);


#Fill the Keyfields
INSERT INTO freekeytext (freekey1) SELECT DISTINCT freekey1 FROM ticket;
INSERT INTO freekeytext (freekey2) SELECT DISTINCT freekey2 FROM ticket;
INSERT INTO freekeytext (freekey3) SELECT DISTINCT freekey3 FROM ticket;
INSERT INTO freekeytext (freekey4) SELECT DISTINCT freekey4 FROM ticket;
INSERT INTO freekeytext (freekey5) SELECT DISTINCT freekey5 FROM ticket;
INSERT INTO freekeytext (freekey6) SELECT DISTINCT freekey6 FROM ticket;
INSERT INTO freekeytext (freekey7) SELECT DISTINCT freekey7 FROM ticket;
INSERT INTO freekeytext (freekey8) SELECT DISTINCT freekey8 FROM ticket;
INSERT INTO freekeytext (freekey9) SELECT DISTINCT freekey9 FROM ticket;
INSERT INTO freekeytext (freekey10) SELECT DISTINCT freekey10 FROM ticket;
INSERT INTO freekeytext (freekey11) SELECT DISTINCT freekey11 FROM ticket;
INSERT INTO freekeytext (freekey12) SELECT DISTINCT freekey12 FROM ticket;
INSERT INTO freekeytext (freekey13) SELECT DISTINCT freekey13 FROM ticket;
INSERT INTO freekeytext (freekey14) SELECT DISTINCT freekey14 FROM ticket;
INSERT INTO freekeytext (freekey15) SELECT DISTINCT freekey15 FROM ticket;
INSERT INTO freekeytext (freekey16) SELECT DISTINCT freekey16 FROM ticket;

#Fill The Textfields
INSERT INTO freekeytext (freetext1) SELECT DISTINCT freetext1 FROM ticket;
INSERT INTO freekeytext (freetext2) SELECT DISTINCT freetext2 FROM ticket;
INSERT INTO freekeytext (freetext3) SELECT DISTINCT freetext3 FROM ticket;
INSERT INTO freekeytext (freetext4) SELECT DISTINCT freetext4 FROM ticket;
INSERT INTO freekeytext (freetext5) SELECT DISTINCT freetext5 FROM ticket;
INSERT INTO freekeytext (freetext6) SELECT DISTINCT freetext6 FROM ticket;
INSERT INTO freekeytext (freetext7) SELECT DISTINCT freetext7 FROM ticket;
INSERT INTO freekeytext (freetext8) SELECT DISTINCT freetext8 FROM ticket;
INSERT INTO freekeytext (freetext9) SELECT DISTINCT freetext9 FROM ticket;
INSERT INTO freekeytext (freetext10) SELECT DISTINCT freetext10 FROM ticket;
INSERT INTO freekeytext (freetext11) SELECT DISTINCT freetext11 FROM ticket;
INSERT INTO freekeytext (freetext12) SELECT DISTINCT freetext12 FROM ticket;
INSERT INTO freekeytext (freetext13) SELECT DISTINCT freetext13 FROM ticket;
INSERT INTO freekeytext (freetext14) SELECT DISTINCT freetext14 FROM ticket;
INSERT INTO freekeytext (freetext15) SELECT DISTINCT freetext15 FROM ticket;
INSERT INTO freekeytext (freetext16) SELECT DISTINCT freetext16 FROM ticket;

Dann müssem in der $HOME/Kernel/System/Ticket.pm noch die folgenden Zeilen geändert werden:

Von:

Code: Select all

$Self->{DBObject}->Prepare(SQL => "SELECT distinct(freetext$Counter) FROM ticket");
$Self->{DBObject}->Prepare(SQL => "SELECT distinct(freekey$Counter) FROM ticket");

In:

Code: Select all

$Self->{DBObject}->Prepare(SQL => "SELECT distinct(freetext$Counter) FROM freekeytext");
$Self->{DBObject}->Prepare(SQL => "SELECT distinct(freekey$Counter) FROM freekeytext");

Nun lädt sich die Suchmaske statt in 40 Sekunden in 2 Sekunden. Der einzige Nachteil ist, dass die Freekeys und Freetexts immer nur tagesaktuell in der Maske stehen, da diese bei uns aber zum Großteil eh vorgegeben sind stört das überhaupt nicht. Ich freue mich auf Diskussionen.

Edit: Stimmt so noch nicht ganz, muss noch angepasst werden, sorry
Edit2: So jetzt ist es angepasst!