
Hallo, die MySQL-DB einer von uns betreuten (2.4.9)-OTRS Instanz ist relativ groß: article_plain umfasst 90GB, article_attachment 67GB. Die MySQL-Datenbank reagiert dadurch (?) inzwischen recht träge; davon abgesehen bekomme ich auch mehr und mehr Angst vor einem Crash und anschließendem myisamchk. Einfache Änderungen (z.B. Aktivierung der statischen Suche) haben wir bereits seit längerem durchgeführt. Hat jemand ähnliche Bedingungen bei OTRS-Instanzen beobachtet? Wie geht Ihr mit solchen Datenmengen um? Gibt es offizielle Empfehlungen seitens OTRS.com? Wir überlegen, ob uns ein Wechsel zu postgrsql etwas bringen könnte? Fährt jemand aus der Community derartig große OTRS-Datenbanken? Gruß Jan Dreyer IT Administrator / Operations Team / M-IT OMS

* Jan.Dreyer@bertelsmann.de
Hallo,
die MySQL-DB einer von uns betreuten (2.4.9)-OTRS Instanz ist relativ groß: article_plain umfasst 90GB, article_attachment 67GB. Die MySQL-Datenbank reagiert dadurch (?) inzwischen recht träge; davon abgesehen bekomme ich auch mehr und mehr Angst vor einem Crash und anschließendem myisamchk. Einfache Änderungen (z.B. Aktivierung der statischen Suche) haben wir bereits seit längerem durchgeführt.
In der Tat ist das ein Problem. Aber man kann ja die Attachments "auslagern" (also direkt auf Platte schreiben). Dadurch schrumpft die DB erheblich. -- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebrandt@charite.de Campus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

Hallo Ralf, ja, die Tabelle "article_attachment" wird danach kleiner. Leider die (noch größere) article_plain nicht :-( Gruß Jan Dreyer IT Administrator / Operations Team / M-IT OMS
-----Ursprüngliche Nachricht----- Von: otrs-de-bounces@otrs.org [mailto:otrs-de-bounces@otrs.org] Im Auftrag von Ralf Hildebrandt Gesendet: Montag, 9. Juli 2012 15:10 An: otrs-de@otrs.org Betreff: Re: [otrs-de] DB-Größe verlangsamt OTRS
* Jan.Dreyer@bertelsmann.de
: Hallo,
die MySQL-DB einer von uns betreuten (2.4.9)-OTRS Instanz ist relativ groß: article_plain umfasst 90GB, article_attachment 67GB. Die MySQL- Datenbank reagiert dadurch (?) inzwischen recht träge; davon abgesehen bekomme ich auch mehr und mehr Angst vor einem Crash und anschließendem myisamchk. Einfache Änderungen (z.B. Aktivierung der statischen Suche) haben wir bereits seit längerem durchgeführt.
In der Tat ist das ein Problem. Aber man kann ja die Attachments "auslagern" (also direkt auf Platte schreiben). Dadurch schrumpft die DB erheblich.
-- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebrandt@charite.de Campus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155 --------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

Hi Jan, On 7/10/12 08:57 , Jan.Dreyer@bertelsmann.de wrote:
ja, die Tabelle "article_attachment" wird danach kleiner. Leider die (noch größere) article_plain nicht :-( JFI: Beim verwenden von bin/otrs.ArticleStorageSwitch.pl werden auch die "Plain" Emals (also die Tabelle "article_plain") ins Filesystem geschrieben.
Wenn die article_plain nicht kleiner wird, dann liegt hier ein Problem/Bug vor.
Gruß Jan Dreyer IT Administrator / Operations Team / M-IT OMS
-- Mike Eduard Enterprise Services for OTRS Znuny GmbH // Marienstraße 11 // 10117 Berlin // Germany P: +49 (0) 30 60 98 54 18-0 F: +49 (0) 30 60 98 54 18-8 W: http://znuny.com Location: Berlin - HRB 139852 B Amtsgericht Berlin-Charlottenburg Managing Director: Martin Edenhofer

Hallo Mike, vielen Dank für diese Info! Ich werde mal nachsehen, warum die Tabelle nicht schrumpft. Vielleicht habe ich auch einfach nicht genau genug hingeschaut ... Gruß Jan Dreyer IT Administrator / Operations Team / M-IT OMS
-----Ursprüngliche Nachricht----- Von: otrs-de-bounces@otrs.org [mailto:otrs-de-bounces@otrs.org] Im Auftrag von Mike Eduard Gesendet: Dienstag, 10. Juli 2012 09:04 An: User questions and discussions about OTRS.org in German Betreff: Re: [otrs-de] DB-Größe verlangsamt OTRS
Hi Jan,
On 7/10/12 08:57 , Jan.Dreyer@bertelsmann.de wrote:
ja, die Tabelle "article_attachment" wird danach kleiner. Leider die (noch größere) article_plain nicht :-( JFI: Beim verwenden von bin/otrs.ArticleStorageSwitch.pl werden auch die "Plain" Emals (also die Tabelle "article_plain") ins Filesystem geschrieben.
Wenn die article_plain nicht kleiner wird, dann liegt hier ein Problem/Bug vor.
Gruß Jan Dreyer IT Administrator / Operations Team / M-IT OMS
-- Mike Eduard Enterprise Services for OTRS
Znuny GmbH // Marienstraße 11 // 10117 Berlin // Germany
P: +49 (0) 30 60 98 54 18-0 F: +49 (0) 30 60 98 54 18-8 W: http://znuny.com
Location: Berlin - HRB 139852 B Amtsgericht Berlin-Charlottenburg Managing Director: Martin Edenhofer
--------------------------------------------------------------------- OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de

Hi Jan, On 7/9/12 14:42 , Jan.Dreyer@bertelsmann.de wrote:
die MySQL-DB einer von uns betreuten (2.4.9)-OTRS Instanz ist relativ groß: article_plain umfasst 90GB, article_attachment 67GB. Die MySQL-Datenbank reagiert dadurch (?) inzwischen recht träge; davon abgesehen bekomme ich auch mehr und mehr Angst vor einem Crash und anschließendem myisamchk. Einfache Änderungen (z.B. Aktivierung der statischen Suche) haben wir bereits seit längerem durchgeführt.
Hat jemand ähnliche Bedingungen bei OTRS-Instanzen beobachtet? Wie geht Ihr mit solchen Datenmengen um? Gibt es offizielle Empfehlungen seitens OTRS.com?
Wir überlegen, ob uns ein Wechsel zu postgrsql etwas bringen könnte? Fährt jemand aus der Community derartig große OTRS-Datenbanken?
Wir haben oft solche Fälle (größer 300GB). Du kannst die Anhänge ins File-System schieben, dies entlastet die Datenbank sehr! a) Für neue Anhänge -> SysConfig -> Ticket -> Core::Ticket -> Ticket::StorageModule -> FS b) Für alle bisherigen Anhänge (nachträglich) -> bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS Hinweis: Du musst beim Backup zukünfig sicherstellen, dass auch das FS mit der Datenbank gesichert wird! Ein einfacher wechsel zu postgrsql bringt keine großartigen Veränderungen. PS: Wir hatten bisher diesbezüglich keinen crash. Du kannst mich aber bei Probemen gerne anschreiben wenn Du Hilfe brauchst. -- Mike Eduard Enterprise Services for OTRS Znuny GmbH // Marienstraße 11 // 10117 Berlin // Germany P: +49 (0) 30 60 98 54 18-0 F: +49 (0) 30 60 98 54 18-8 W: http://znuny.com Location: Berlin - HRB 139852 B Amtsgericht Berlin-Charlottenburg Managing Director: Martin Edenhofer
participants (3)
-
Jan.Dreyer@bertelsmann.de
-
Mike Eduard
-
Ralf Hildebrandt