MariaDB, DB wächst (zu) schnell

[Exxter]

Hallo,

ich habe auf einem Debian Jessie 64bit ein OTRS 4 mit MariaDB (original von Debian) laufen. Schon seit längerem beobachte ich ein schnelles Wachstum der Datenbank:

38955

Natürlich kommen oft Mails mit Anhängen ins OTRS, doch nicht mit einer Gesamtgröße von 200MB. Ich habe mir die Tickets von den Tagen angeschaut, wo es ca 200MB gewachsen ist, das ist, denke ich, nicht die Ursache.

Da OTRS Fehler ausspuckte und als Lösung nannte, man soll den Wert innodb_log_file_size auf 300M setzen, habe ich das natürlich gemacht. Ich vermute, seit dem wächst die DB so schnell. Ich habe kein gutes Gefühl dabei, das so zu lasse.

Ich habe natürlich gesucht und einige Infos gefunden:

http://schreibtischwerkstatt.de/mysql-m ... ir-wechel/

https://blog.secretisland.de/mysql-inno ... instellen/

Jetzt bleibt aber immer ein Risiko dabei, wenn ich das vom letzten Link umsetze kann ich zwar vorher ein Backup machen, aber ich sehe nicht sofort danach, ob es tatsächlich die Lösung des Problems ist. Da im OTRS täglich ca 8 Agents arbeiten, kann ich dann auch kaum zurück zum Backup. Deswegen wollte ich euch fragen, ob das ratsam ist, das so umzusetzen oder ob es noch andere Ursachen / Lösungen gibt?

In der /etc/mysql/my.cnf habe ich nur folgende Werte geändert:

max_allowed_packet = 50M
innodb_log_file_size = 300M
[mysqldump]
max_allowed_packet = 50M

Alles andere ist Standard.

Jemand eine Idee dazu?

[pferdefreund]

Na ja, je nachdem was da für Daten kommen braucht die Datenbank unter Umständen das mehrfache an Platz, wie die Originaldaten - insbesondere wenn es viele Indexe auf die Tabellen gibt. Da stellt sich für mich die Frage - kann da ggf. was archiviert werden ? Das Thema wird gerne zurückgestellt und anschließend ist das Geheule gross, wenn der Platzbedarf wächst und die Performance in den Keller geht. Habe das in meiner über 30 jährigen Zeit in der EDV - damals gab es noch keine IT - schon oft genug erlebt. Wobei - eine echte Archivierung ist die Auslagerung auf einen externen Bestand (unveränderbar) und kein logisches Aufteilen auf mehrere DB's, was auch oft gerne gemacht wird um mal schnell eine Lösung zu haben.

[heisenberg]

Also grundsätzlich, wenn Du noch nicht viel Erfahrung mit MySQL und Sicherungs- und Wiederherstellungsprozeduren hast: Mach' mal 'ne Sicherung und spiele die Sicherung auf einem Testsystem wieder her. Ich hatte in der Vergangenheit schon Werte bei InnoDB verändert, die ich besser nicht angefasst hätte. (Das war glaube ich die innodb_pool_buffer_size). Da ist dann mal gar nix mehr gestartet.

Falls Du wirklich von InnoDB auf MyISAM umstellen willst - ich würde das nicht tun - darauf achten, dass wirklich alle Tabellen umgestellt werden. Hier was zum Thema gemischte StorageEngines und OTRS:

http://blog.otrs.org/2013/02/20/about-o ... e-engines/

Du kannst Dir auch mal mit HeidiSQL die DB anschauen. Dort siehst Du schön die Speicherplatzverteilung innerhalb der einzelnen DBs. HeidiSQL ist eine Windows GPL Anwendung - das beste MySQL-Admin-GUI-Tool - das ich kenne. Läuft einwandfrei unter Linux per Wine.

[Exxter]

Na ja, je nachdem was da für Daten kommen braucht die Datenbank unter Umständen das mehrfache an Platz, wie die Originaldaten - insbesondere wenn es viele Indexe auf die Tabellen gibt. Da stellt sich für mich die Frage - kann da ggf. was archiviert werden ? Das Thema wird gerne zurückgestellt und anschließend ist das Geheule gross, wenn der Platzbedarf wächst und die Performance in den Keller geht. Habe das in meiner über 30 jährigen Zeit in der EDV - damals gab es noch keine IT - schon oft genug erlebt. Wobei - eine echte Archivierung ist die Auslagerung auf einen externen Bestand (unveränderbar) und kein logisches Aufteilen auf mehrere DB's, was auch oft gerne gemacht wird um mal schnell eine Lösung zu haben.

Ja, OTRS bietet eine Archivierungsfunktion, die wollte ich aber erst später nutzen. Es ist nicht das Problem, dass der Platz knapp wird, es sind aktuell 11% der var-Partition benutzt, und da es als VM läuft, kann man die Partition auch nachträglich vergrößern. Aber mir geht etwas die Muffe, wenn die DB weiterhin so schnell wächst. Wenn das so normal ist, ok, dann muss es so sein. Wenn aber irgendwelche Einstellungen / Logdateien dieses Wachstum auslösen, dann würde ich jetzt etwas dagegen unternehmen wolle.

[Exxter]

Also grundsätzlich, wenn Du noch nicht viel Erfahrung mit MySQL und Sicherungs- und Wiederherstellungsprozeduren hast: Mach' mal 'ne Sicherung und spiele die Sicherung auf einem Testsystem wieder her. Ich hatte in der Vergangenheit schon Werte bei InnoDB verändert, die ich besser nicht angefasst hätte. (Das war glaube ich die innodb_pool_buffer_size). Da ist dann mal gar nix mehr gestartet.

Falls Du wirklich von InnoDB auf MyISAM umstellen willst - ich würde das nicht tun - darauf achten, dass wirklich alle Tabellen umgestellt werden. Hier was zum Thema gemischte StorageEngines und OTRS:

http://blog.otrs.org/2013/02/20/about-o ... e-engines/

Du kannst Dir auch mal mit HeidiSQL die DB anschauen. Dort siehst Du schön die Speicherplatzverteilung innerhalb der einzelnen DBs. HeidiSQL ist eine Windows GPL Anwendung - das beste MySQL-Admin-GUI-Tool - das ich kenne. Läuft einwandfrei unter Linux per Wine.

Das Sichern und Wiederherstellen der DB werde ich gleich mal testen. Mache zwar bisher mehrere Backups mit mysqldump, aber wiederhergestellt habe ich noch keines. Das HeidiSQL-Tool werde ich mir gleich mal anschauen, das klingt sehr nützlich.

[heisenberg]

Im übrigen:

Du hast die Grösse der Dump-Dateien gezeigt. Das hat mit den MySQL-(Binary)-Logs erst Mal nix zu tun. Das müssten dann ja schon die reinen Anwendungsdaten sein.

[Exxter]

Im übrigen:

Du hast die Grösse der Dump-Dateien gezeigt. Das hat mit den MySQL-(Binary)-Logs erst Mal nix zu tun. Das müssten dann ja schon die reinen Anwendungsdaten sein.

Ah, OK, dh. die Logs werden nicht mit gedumpt? Also direkt im Verzeichnis der DB ein 'du -sm' ergibt 6945, im /var/lib/mysql/ ergibt es ein 7764. Hab das gleich mal in mein Script eingebaut dass er den Wert auch loggt. Auf der VM läuft nur OTRS, sonst nichts.

Ansonsten habe ich die DB exportiert und auf einer anderen VM wieder importiert, lief ohne Probleme. HeidiSQL zeigt:



Sieht für mich so aus, als ob die Größe tatsächlich OK ist und nicht nur von den Logs kommt, oder?

[rendegast]

Nur so aus Interesse,
wieviel bleibt von so einer backup.sql übrig beim 'gzip -1'?

[heisenberg]

Ich empfehle Dir die Attachments - sofern möglich - nicht in der DB zu speichern sondern im Dateisystem. Grund dafür ist, dass ab einer gewissen Grösse die (MySQL-) Datenbanken irgendwann sehr unangenehm zu verwalten werden. Unsere Mail-DB(Zarafa in sehr alter Version mit 18 GB Grösse) hat mich schon einiges an Nerven gekostet.

Siehe z. B. :
http://ger.oza.hn/2012/03/otrs-attachme ... datenbank/

Ansonsten: Du kannst auch Portforwarding bei der SSH-Verbindung zum Produktiv-DB-Server verwenden, dann kannst Du mit der Heidi auch dort direkt reinschauen.

[Dimejo]

Ansonsten habe ich die DB exportiert und auf einer anderen VM wieder importiert, lief ohne Probleme. HeidiSQL zeigt:



Sieht für mich so aus, als ob die Größe tatsächlich OK ist und nicht nur von den Logs kommt, oder?

Ich habe zwar kein Ahnung von OTRS, aber article_attachment hat doppelt so viele Einträge wie article_plain und ist trotzdem 700MiB kleiner? Was steht denn in article_plain das 0,4MiB pro Zeile benötigt? Das kommt mir etwas viel vor.

[Exxter]

Ich empfehle Dir die Attachments - sofern möglich - nicht in der DB zu speichern sondern im Dateisystem. Grund dafür ist, dass ab einer gewissen Grösse die (MySQL-) Datenbanken irgendwann sehr unangenehm zu verwalten werden. Unsere Mail-DB(Zarafa in sehr alter Version mit 18 GB Grösse) hat mich schon einiges an Nerven gekostet.

Siehe z. B. :
http://ger.oza.hn/2012/03/otrs-attachme ... datenbank/

Du hast Recht, guter Link, werde ich so umsetzen.

Nur so aus Interesse,
wieviel bleibt von so einer backup.sql übrig beim 'gzip -1'?

otrstest.sql = 6,6GB
otrstest.sql.gz = 5,2GB (mit gzip -1)

Ansonsten weiß ich jetzt, was ich zu tun habe. Vielen herzlichen Dank euch!

[heisenberg]

Würde mich interessieren was so die Ergebnisse sind. Den Einwurf von Dimejo finde ich sehr gut. Was zum Geier braucht 400k pro Zeile?

[Exxter]

Würde mich interessieren was so die Ergebnisse sind. Den Einwurf von Dimejo finde ich sehr gut. Was zum Geier braucht 400k pro Zeile?

Problem ist, ich kann da nicht jeder Zeit ran. Ich habe mir article_plain mal genauer angeschaut. Die Anzeige sagt mir nicht viel:

http://img5.fotos-hochladen.net/uploads ... yu2tsv.png

Finde keine Möglichkeit, die Zeilen nach Größe zu sortieren bzw. überhaupt eine Größe anzuzeigen.

Wonach würdet ihr schauen?

[heisenberg]

Hier ist mal ein passendes SQL-Statement dazu(Kannst Du auch in der Heidi eingeben):

Code: Alles auswählen

select id, article_id, char_length(body) as size from article_plain order by size desc limit 1000;

[Exxter]

Hier ist mal ein passendes SQL-Statement dazu(Kannst Du auch in der Heidi eingeben):

Code: Alles auswählen

select id, article_id, char_length(body) as size from article_plain order by size desc limit 1000;

Gemacht unter "Abfrage", erstes Ergebnis ist id=407 article_id=522 size=35.920.620

Wenn ich zurück auf "Daten" wechsle und dort die id 407 und article_id 522 suche, hängt er beim anklicken der Zeile erstmal.
Ein weiterer Screenshot:

http://img5.fotos-hochladen.net/uploads ... yi2p35.png

Hmm, ich muss gestehen, das sagt mir nicht viel

[heisenberg]

Gemacht unter "Abfrage", erstes Ergebnis ist id=407 article_id=522 size=35.920.620

Wenn ich zurück auf "Daten" wechsle und dort die id 407 und article_id 522 suche, hängt er beim anklicken der Zeile erstmal.
Ein weiterer Screenshot:

Hmm, ich muss gestehen, das sagt mir nicht viel.

Das bedeutet, dass der Inhalt vom Feld body im gefundenen ersten Datensatz 35 MB gross ist(Der 1. Datensatz ist der grösste). Deswegen hängt der beim anklicken der Zeile.

Je nachdem wie kurz oder lang OTRS das läuft würde ich mir Gedanken machen. Ich habe ja bisher den Eindruck dass das noch nicht so lange im Einsatz ist.