otrs mit mysql/mariadb sql benchmark extrem langsam (OS 12.2)
Hallo, Der interne SQL Benchmark des OTRS Support-Assessment-Modul(1xNormal ca. 25 sec) ist extrem langsam bzw. kommt nicht zum Schluss. Beim "run-all-tests" Benchmark verhält sich das System ebenso langsam. Als System läuft OS 12.2 x86_64 auf einem HP Microserver N40L (CPU: AMD TurionII N40L). Als Ursache konnte ich den Mysql Community Server ausmachen. Mit MariaDB als Server verhält es sich genauso. Abhilfe brachte nur eine Umstellung der Storage Engine des DB-Servers von InnoDB auf MyISAM. Eintrag in my.cnf "default-storage-engine=myisam" Bei Nutzung der InnoDB Engine ist I/O Last der HDD während der Tests extrem hoch während die CPU kaum etwas zu tun hat. Bei einem Test in einer VMware mit 32bit OS 12.2 und anderer CPU(Intel(R) Xeon(TM) CPU 3.40GHz) waren die Auswirkungen nicht festzustellen. Meine Frage ist schon ein Bug zu diesem Problem bekannt? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Donnerstag, 27. Dezember 2012, 13:07:17 schrieb Mirko Schneider:
(...).
Überprüf mal ob die Mount-Option "barriers" die Ursache ist: http://michal.hrusecky.net/2009/11/barriers-ext4-mysql/ IMHO ist es einen Versuch auch dann Wert, wenn du kein ext4 benutzt.
Meine Frage ist schon ein Bug zu diesem Problem bekannt?
Falls es obiges ist, ja, aber es ist kein Bug: https://bugzilla.novell.com/show_bug.cgi?id=549534 Gruß Jan -- Paper is always strongest at the perforations. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 27.12.2012 13:07, schrieb Mirko Schneider:
Hallo,
Der interne SQL Benchmark des OTRS Support-Assessment-Modul(1xNormal ca. 25 sec) ist extrem langsam bzw. kommt nicht zum Schluss. Beim "run-all-tests" Benchmark verhält sich das System ebenso langsam. Als System läuft OS 12.2 x86_64 auf einem HP Microserver N40L (CPU: AMD TurionII N40L).
Als Ursache konnte ich den Mysql Community Server ausmachen. Mit MariaDB als Server verhält es sich genauso. Abhilfe brachte nur eine Umstellung der Storage Engine des DB-Servers von InnoDB auf MyISAM. Eintrag in my.cnf "default-storage-engine=myisam" Bei Nutzung der InnoDB Engine ist I/O Last der HDD während der Tests extrem hoch während die CPU kaum etwas zu tun hat. Bei einem Test in einer VMware mit 32bit OS 12.2 und anderer CPU(Intel(R) Xeon(TM) CPU 3.40GHz) waren die Auswirkungen nicht festzustellen.
Meine Frage ist schon ein Bug zu diesem Problem bekannt?
Da ich mich mit OTRS nicht auskenne: Hast Du eine Beschreibung (Link), was dieser Benchmark macht? Generell: - Version von MySQL? - my.cnf ? (zumindest die Abweichungen von den Standard-Werten) - Festplattenkonfiguration mit mount-Optionen ? MyISAM macht im Gegensatz zu InnoDb keine Transaktionen und sperrt nur ganze Tabellen statt Zeilen; spart sich also jede Menge (IO-)Arbeit. mfg Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, dies könnte damit zusammen hängen, dass bei InnoDB per Default innodb_flush_log_at_trx_commit = 1 eingestellt ist. Die Auswirkungen von diesem Parameter sind hier beschrieben: http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_... Ich könnte mir vorstellen, dass VMWare den flush auf die Disk nur cached, und nicht wirklich durchführt. Wie sich VMWare tatsächlich, bei einem write mit O_DIRECT verhält, weiß ich allerdings nicht genau. Um zu verifizieren ob es hieran liegt, würde ich den Parameter innodb_flush_log_at_trx_commit auf 2 stellen und den Test erneut ausführen. Gruß Dirk Am 27.12.2012 19:45, schrieb Hendrik Woltersdorf:
Am 27.12.2012 13:07, schrieb Mirko Schneider:
Hallo,
Der interne SQL Benchmark des OTRS Support-Assessment-Modul(1xNormal ca. 25 sec) ist extrem langsam bzw. kommt nicht zum Schluss. Beim "run-all-tests" Benchmark verhält sich das System ebenso langsam. Als System läuft OS 12.2 x86_64 auf einem HP Microserver N40L (CPU: AMD TurionII N40L).
Als Ursache konnte ich den Mysql Community Server ausmachen. Mit MariaDB als Server verhält es sich genauso. Abhilfe brachte nur eine Umstellung der Storage Engine des DB-Servers von InnoDB auf MyISAM. Eintrag in my.cnf "default-storage-engine=myisam" Bei Nutzung der InnoDB Engine ist I/O Last der HDD während der Tests extrem hoch während die CPU kaum etwas zu tun hat. Bei einem Test in einer VMware mit 32bit OS 12.2 und anderer CPU(Intel(R) Xeon(TM) CPU 3.40GHz) waren die Auswirkungen nicht festzustellen.
Meine Frage ist schon ein Bug zu diesem Problem bekannt?
Da ich mich mit OTRS nicht auskenne: Hast Du eine Beschreibung (Link), was dieser Benchmark macht? Generell: - Version von MySQL? - my.cnf ? (zumindest die Abweichungen von den Standard-Werten) - Festplattenkonfiguration mit mount-Optionen ?
MyISAM macht im Gegensatz zu InnoDb keine Transaktionen und sperrt nur ganze Tabellen statt Zeilen; spart sich also jede Menge (IO-)Arbeit.
mfg Hendrik
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Erst einmal Dank für die vielen Hinweise und ein Gesundes Neues Jahr, Ziel war eigentlich nur ein kleines OTRS Testsystem als Xen PV DomU auf bekannter HW. Nachdem sich dort die Performanceprobleme zeigten machte ich mich auf die Suche nach der Ursache. Ich nutze für die DB immer eine eigene Partition bzw. HDD mit XFS So hier nun meine Ergebnisse nach sämtlichen Tests: - Mount Optionen für XFS noatime >keine merkliche Änderung nobarrier >erheblich schneller(OTRS Benchmark nutzbar) aber noch viel I/O auf der HDD - Anpassungen in my.cnf flush_log_at_trx_commit = 2 > I/O Last während des Tests kaum noch vorhanden Eine kurze Beschreibung des Benchmark vom OTRS Support Assessment Modul: Benchmark in einer separaten Tabelle, mit 10000 Inserts/Updates/Selects/Deletes und die dafür benötigte Zeit. Hier mal eine Beispielausgabe mit InnoDB Engine nach der Optimierung Mount Option "nobarriers": Insert Time: 10000 24 s :-( Should not take more than 5's on an average system. Update Time: 10000 25 s :-( Should not take more than 9's on an average system. Select Time: 10000 7 s :-( Should not take more than 6's on an average system. Delete Time: 10000 6 s :-( Should not take more than 5's on an average system. Multiplier: * 1 Und zusätzlich mit "flush_log_at_trx_commit = 2" in my.cnf: Insert Time: 10000 6 s :-( Should not take more than 5's on an average system. Update Time: 10000 8 s Ok Select Time: 10000 6 s Ok Delete Time: 10000 6 s :-( Should not take more than 5's on an average system. Multiplier: * 1 Und hier eine Beispielausgabe meiner OTRS Testumgebung mit MyISAM Engine auf gleicher HW aber als Xen PV DomU(OS12.2) Wobei hier der OpenXen Dom0(OS12.1) mit einem SW RAID5(4x2TB) läuft. Insert Time: 10000 2 s :-) Looks fine! Update Time: 10000 4 s :-) Looks fine! Select Time: 10000 4 s :-) Looks fine! Delete Time: 10000 3 s :-) Looks fine! Multiplier: * 1 FAZIT: Da OTRS z.Z. die Vorteile der InnoDB Engine(Transaktionen) nicht wirklich nutzt, Umstellung auf MyISAM da immer noch schneller als InnoDB. Wenn man aber unbedingt die InnoDB Engine nutzen will Mount Optionen noatime, nobarrier und my.cnf auf flush_log_at_trx_commit = 2 setzen. Gruß Mirko
-----Ursprüngliche Nachricht----- Von: Dirk Hartmann [mailto:dirk@framelabs.net] Gesendet: Donnerstag, 27. Dezember 2012 20:37 An: opensuse-de@opensuse.org Betreff: Re: otrs mit mysql/mariadb sql benchmark extrem langsam (OS 12.2)
Hallo,
dies könnte damit zusammen hängen, dass bei InnoDB per Default innodb_flush_log_at_trx_commit = 1 eingestellt ist.
Die Auswirkungen von diesem Parameter sind hier beschrieben:
http://dev.mysql.com/doc/refman/5.5/en/innodb- parameters.html#sysvar_innodb_flush_log_at_trx_commit
Ich könnte mir vorstellen, dass VMWare den flush auf die Disk nur cached, und nicht wirklich durchführt. Wie sich VMWare tatsächlich, bei einem write mit O_DIRECT verhält, weiß ich allerdings nicht genau.
Um zu verifizieren ob es hieran liegt, würde ich den Parameter innodb_flush_log_at_trx_commit auf 2 stellen und den Test erneut ausführen.
Gruß Dirk
Am 27.12.2012 19:45, schrieb Hendrik Woltersdorf:
Am 27.12.2012 13:07, schrieb Mirko Schneider:
Hallo,
Der interne SQL Benchmark des OTRS Support-Assessment- Modul(1xNormal ca. 25 sec) ist extrem langsam bzw. kommt nicht zum Schluss. Beim "run-all-tests" Benchmark verhält sich das System ebenso langsam. Als System läuft OS 12.2 x86_64 auf einem HP Microserver N40L (CPU: AMD TurionII N40L).
Als Ursache konnte ich den Mysql Community Server ausmachen. Mit MariaDB als Server verhält es sich genauso. Abhilfe brachte nur eine Umstellung der Storage Engine des DB- Servers von InnoDB auf MyISAM. Eintrag in my.cnf "default-storage-engine=myisam" Bei Nutzung der InnoDB Engine ist I/O Last der HDD während der Tests extrem hoch während die CPU kaum etwas zu tun hat. Bei einem Test in einer VMware mit 32bit OS 12.2 und anderer CPU(Intel(R) Xeon(TM) CPU 3.40GHz) waren die Auswirkungen nicht festzustellen.
Meine Frage ist schon ein Bug zu diesem Problem bekannt?
Da ich mich mit OTRS nicht auskenne: Hast Du eine Beschreibung (Link), was dieser Benchmark macht? Generell: - Version von MySQL? - my.cnf ? (zumindest die Abweichungen von den Standard-Werten) - Festplattenkonfiguration mit mount-Optionen ?
MyISAM macht im Gegensatz zu InnoDb keine Transaktionen und sperrt nur ganze Tabellen statt Zeilen; spart sich also jede Menge (IO-)Arbeit.
mfg Hendrik
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 02.01.2013 17:20, schrieb Mirko Schneider:
Erst einmal Dank für die vielen Hinweise und ein Gesundes Neues Jahr,
Ziel war eigentlich nur ein kleines OTRS Testsystem als Xen PV DomU auf bekannter HW. Nachdem sich dort die Performanceprobleme zeigten machte ich mich auf die Suche nach der Ursache.
Ich nutze für die DB immer eine eigene Partition bzw. HDD mit XFS
So hier nun meine Ergebnisse nach sämtlichen Tests:
- Mount Optionen für XFS noatime >keine merkliche Änderung nobarrier >erheblich schneller(OTRS Benchmark nutzbar) aber noch viel I/O auf der HDD
- Anpassungen in my.cnf flush_log_at_trx_commit = 2 > I/O Last während des Tests kaum noch vorhanden
Eine kurze Beschreibung des Benchmark vom OTRS Support Assessment Modul:
Benchmark in einer separaten Tabelle, mit 10000 Inserts/Updates/Selects/Deletes und die dafür benötigte Zeit.
Hier mal eine Beispielausgabe mit InnoDB Engine nach der Optimierung Mount Option "nobarriers":
Insert Time: 10000 24 s :-( Should not take more than 5's on an average system. Update Time: 10000 25 s :-( Should not take more than 9's on an average system. Select Time: 10000 7 s :-( Should not take more than 6's on an average system. Delete Time: 10000 6 s :-( Should not take more than 5's on an average system. Multiplier: * 1
Und zusätzlich mit "flush_log_at_trx_commit = 2" in my.cnf:
Insert Time: 10000 6 s :-( Should not take more than 5's on an average system. Update Time: 10000 8 s Ok Select Time: 10000 6 s Ok Delete Time: 10000 6 s :-( Should not take more than 5's on an average system. Multiplier: * 1
Und hier eine Beispielausgabe meiner OTRS Testumgebung mit MyISAM Engine auf gleicher HW aber als Xen PV DomU(OS12.2) Wobei hier der OpenXen Dom0(OS12.1) mit einem SW RAID5(4x2TB) läuft.
Insert Time: 10000 2 s :-) Looks fine! Update Time: 10000 4 s :-) Looks fine! Select Time: 10000 4 s :-) Looks fine! Delete Time: 10000 3 s :-) Looks fine! Multiplier: * 1
FAZIT:
Da OTRS z.Z. die Vorteile der InnoDB Engine(Transaktionen) nicht wirklich nutzt, Umstellung auf MyISAM da immer noch schneller als InnoDB.
Wenn man aber unbedingt die InnoDB Engine nutzen will Mount Optionen noatime, nobarrier und my.cnf auf flush_log_at_trx_commit = 2 setzen.
Gruß Mirko
Das deckt sich mit meinen Tests mit dem MySQL-eigenen Benchmark auf meinem 9 Jahre alten Laptop. Für ein Testsystem ist es OK, die Schreibcaches auf allen Ebenen zu aktivieren, aber für den Produktiveinsatz sollte man sich gut überlegen, ob man die damit verbundene Gefahr des Datenverlusts eingehen möchte. Das OTRS im Jahre 2013 noch keine Transaktionen benutzt, finde ich erschreckend... Das einzige Bug-würdige, was mir bei den Tests aufgefallen ist, ist die Tatsache, dass die MySQL-Pakete von openSUSE ohne Unterstützung für asynchrones IO (libaio) gebaut sind. Auf der schwachbrüstigen Hardware, über die wir hier reden, spielt das keine Rolle, aber auf entsprechend ausgestatteten Servern kann das schlimmstenfalls bis zu 40% Performance kosten. Ein Gesundes Neues, Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Hendrik, hallo Leute, Am Mittwoch, 2. Januar 2013 schrieb Hendrik Woltersdorf:
Am 02.01.2013 17:20, schrieb Mirko Schneider:
nobarrier >erheblich schneller(OTRS Benchmark nutzbar) aber noch viel I/O auf der HDD> - Anpassungen in my.cnf
flush_log_at_trx_commit = 2 > I/O Last während des Tests kaum noch vorhanden>
Kurzer Einwurf für diejenigen, die gerade nur Bahnhof verstehen: http://blog.koehntopp.de/archives/1997-Die-InnoDB-Storage-Engine-Konfigurati...
Hier mal eine Beispielausgabe mit InnoDB Engine nach der Optimierung Mount Option "nobarriers":
Und zusätzlich mit "flush_log_at_trx_commit = 2" in my.cnf:
Klar, das macht die Schreiboperationen - kaum überraschend - deutlich schneller, weil nicht nach jedem commit auf die Platte gewartet werden muss. Was mich mal interessieren würde: Hast Du auch Werte für andere Kombinationen? Interessant wäre IMHO vor allem die Variante mit "flush_log_at_trx_commit = 2" und ohne nobarrier.
Und hier eine Beispielausgabe meiner OTRS Testumgebung mit MyISAM Engine auf gleicher HW aber als Xen PV DomU(OS12.2) Wobei hier der OpenXen Dom0(OS12.1) mit einem SW RAID5(4x2TB) läuft.
Jepp. MyISAM kennt kein Log und keine Transaktionen - kein Wunder, dass es schneller ist.
Wenn man aber unbedingt die InnoDB Engine nutzen will Mount Optionen noatime, nobarrier und my.cnf auf flush_log_at_trx_commit = 2 setzen.
Das deckt sich mit meinen Tests mit dem MySQL-eigenen Benchmark auf meinem 9 Jahre alten Laptop. Für ein Testsystem ist es OK, die Schreibcaches auf allen Ebenen zu aktivieren, aber für den Produktiveinsatz sollte man sich gut überlegen, ob man die damit verbundene Gefahr des Datenverlusts eingehen möchte.
Genau. Deswegen auch meine Frage nach der Kombination "flush_log_at_trx_commit = 2" ohne nobarrier, weil das zumindest MySQL- Crashes problemlos übersteht. Ein Crash des kompletten Betriebssystems (oder ein Stromausfall) wird dadurch natürlich nicht abgedeckt - aber dieses Risiko (bzw. der dadurch entstehende Schaden) ist in den meisten Einsatzbereichen zu verschmerzen.
Das einzige Bug-würdige, was mir bei den Tests aufgefallen ist, ist die Tatsache, dass die MySQL-Pakete von openSUSE ohne Unterstützung für asynchrones IO (libaio) gebaut sind. Auf der schwachbrüstigen Hardware, über die wir hier reden, spielt das keine Rolle, aber auf entsprechend ausgestatteten Servern kann das schlimmstenfalls bis zu 40% Performance kosten.
Zeigst Du mir bitte mal den zugehörigen Bugreport? ;-) Gruß Christian Boltz -- Es gibt in Mailformaten keinen Individualismus. Es gibt sehr detailliert REGELN (nämlich die RFCs), die solche Sachen auf Punkt und Komma vorschreiben, und wer das witzigerweise anders macht, fährt auf der falschen Straßenseite und kommt unter die Räder. [Ratti in suse-linux] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
-----Ursprüngliche Nachricht----- Von: Christian Boltz [mailto:suse@cboltz.de] Gesendet: Mittwoch, 2. Januar 2013 22:37 An: opensuse-de@opensuse.org Betreff: Re: otrs mit mysql/mariadb sql benchmark extrem langsam (OS 12.2)
Hallo Hendrik, hallo Leute,
Am Mittwoch, 2. Januar 2013 schrieb Hendrik Woltersdorf:
Am 02.01.2013 17:20, schrieb Mirko Schneider:
nobarrier >erheblich schneller(OTRS Benchmark nutzbar) aber noch viel I/O auf der HDD> - Anpassungen in my.cnf
flush_log_at_trx_commit = 2 > I/O Last während des Tests kaum noch vorhanden>
Kurzer Einwurf für diejenigen, die gerade nur Bahnhof verstehen: http://blog.koehntopp.de/archives/1997-Die-InnoDB-Storage-Engine- Konfiguration.html
Hier mal eine Beispielausgabe mit InnoDB Engine nach der Optimierung Mount Option "nobarriers":
Und zusätzlich mit "flush_log_at_trx_commit = 2" in my.cnf:
Klar, das macht die Schreiboperationen - kaum überraschend - deutlich schneller, weil nicht nach jedem commit auf die Platte gewartet werden muss.
Was mich mal interessieren würde: Hast Du auch Werte für andere Kombinationen? Interessant wäre IMHO vor allem die Variante mit "flush_log_at_trx_commit = 2" und ohne nobarrier.
Und hier eine Beispielausgabe meiner OTRS Testumgebung mit MyISAM Engine auf gleicher HW aber als Xen PV DomU(OS12.2) Wobei hier der OpenXen Dom0(OS12.1) mit einem SW RAID5(4x2TB) läuft.
Jepp. MyISAM kennt kein Log und keine Transaktionen - kein Wunder, dass es schneller ist.
Wenn man aber unbedingt die InnoDB Engine nutzen will Mount Optionen noatime, nobarrier und my.cnf auf flush_log_at_trx_commit = 2 setzen.
Das deckt sich mit meinen Tests mit dem MySQL-eigenen Benchmark auf meinem 9 Jahre alten Laptop. Für ein Testsystem ist es OK, die Schreibcaches auf allen Ebenen zu aktivieren, aber für den Produktiveinsatz sollte man sich gut überlegen, ob man die damit verbundene Gefahr des Datenverlusts eingehen möchte.
Genau. Deswegen auch meine Frage nach der Kombination "flush_log_at_trx_commit = 2" ohne nobarrier, weil das zumindest MySQL- Crashes problemlos übersteht. Hier noch die gewünschten Werte des OTRS Support Modul ohne nobarrier und ohne Virtualisierung aber gleiche HW. Wert "innodb_flush_log_at_trx_commit = 2" in my.cnf DB Engine ist InnoDB
Insert Time: 10000 6 s :-( Should not take more than 5's on an average system. Update Time: 10000 8 s Ok Select Time: 10000 6 s Ok Delete Time: 10000 6 s :-( Should not take more than 5's on an average system. Multiplier: * 1
Ein Crash des kompletten Betriebssystems (oder ein Stromausfall) wird dadurch natürlich nicht abgedeckt - aber dieses Risiko (bzw. der dadurch entstehende Schaden) ist in den meisten Einsatzbereichen zu verschmerzen.
Gruß Mirko -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 02.01.2013 22:37, schrieb Christian Boltz:
Das einzige Bug-würdige, was mir bei den Tests aufgefallen ist, ist die Tatsache, dass die MySQL-Pakete von openSUSE ohne Unterstützung für asynchrones IO (libaio) gebaut sind. Auf der schwachbrüstigen Hardware, über die wir hier reden, spielt das keine Rolle, aber auf entsprechend ausgestatteten Servern kann das schlimmstenfalls bis zu 40% Performance kosten.
Zeigst Du mir bitte mal den zugehörigen Bugreport? ;-)
Gruß
Christian Boltz
Aber klar doch: https://bugzilla.novell.com/show_bug.cgi?id=796164 mfg Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Christian Boltz -
Dirk Hartmann -
Hendrik Woltersdorf -
Jan Ritzerfeld -
Mirko Schneider