MySQL 5.5 verschlechterte die Leistung im Linux-Kernel 3.2 im Vergleich zu 2.6

7

Unsere Datenbankserver (hauptsächlich basierend auf den stabilen Debian-Paketen (= derzeit Wheezy)) scheinen bei gleicher Arbeitslast im Kernel etwa viermal mehr Last zu haben als 3.2.0-4-amd64im vorherigen 2.6.32-5-amd64Kernel. Wenn alle Pakete gleich sind und im anderen Kernel booten, können wir dies eindeutig Ich sehe den Unterschied und weiß nicht, warum. Das Problem ist, dass ich nicht so viele Unterschiede bei der E / A- oder CPU-Last sehe.

Das Setzen der Standardeinstellung kernel.sched_min_granularity_nsund das Zurücksetzen kernel.sched_latency_nsauf die 2.6.32Werte hilft ein wenig (dreimal statt viermal), aber nicht auf das gewünschte Niveau. Da sich viele Kerneleinstellungen geändert haben, können wir den neuen Kernel kaum blind auf die alten Standardwerte des 2.6einen setzen.

Hat noch jemand Erfahrung damit? Wenn ja, was hat dies verursacht (und im Idealfall: Wie könnte es gelöst werden)?

Da es sich um einen tiefen Kernel handelt, könnte möglicherweise ein Unterschied in den Sysctl-Werten von Interesse sein: Hier ist ein Unterschied der 2 (eingefügt, um eine zu lange Frage zu vermeiden).

Bearbeiten : Derzeit untersuchen wir diese SO-Antwort , um festzustellen, ob dies zutrifft.

Wrikken
quelle
1
Ich vermute, Sie haben überprüft, ob die my.cnf-Dateien auf beiden Computern gleich sind.
Symcbean
Ja, ganz einfach ... denn auf demselben Computer muss nur der eine oder andere Kernel gebootet werden. Nichts auf der Festplatte ist anders. Dieses Verhalten ist bei den Starts in 2.6 und 3.2 konsistent. (Und bleibt über einen längeren Zeitraum gleich, dh: Wenn Sie eine Woche in einer und eine Woche in der anderen ausführen, erhalten Sie das gleiche Ergebnis, sodass es sich nicht um ein Problem mit kaltem Cache / Speicher handelt.)
Wrikken
und ALLE Pakete, alle anderen Konfigurationsdateien sind gleich? gleiche Hardwarekonfiguration, gleiche Speicherkonfiguration, gleiche Hardwareeinstellungen usw.? Es gibt einen großen Unterschied zwischen den letzten Kernelversionen im Scheduler, aber dieser Unterschied sollte nicht spürbar sein.
GioMac
Alles, wie gesagt, derselbe Server, nur mit einem anderen Kernel, zeigt dieses Verhalten. Ich könnte mir vorstellen, dass die 'Standardeinstellungen' eines Kernels nicht ideal für das Biest sind, das unsere DB-Maschine ist, aber es hat uns noch nie
gestört
sogar Dateispeicherorte auf physischer Ebene? :) versuche einfach den Kernel zu tauschen.
GioMac

Antworten:

2

Linux-Kernel 3.0 - 3.8 sollten vermieden oder aktualisiert werden, um die Verschlechterung der E / A-Leistung zu beheben

Die Leistungsverschlechterung der Linux-Kernel-E / A wurde von Josh Berkus anhand einer privaten Benchmark-Workload demonstriert, die unter PostgreSQL 9.3 unter Ubuntu 12.04 mit Kernel 3.2.0 ausgeführt wird.

"... Sie müssen wirklich jeden Kernel zwischen 3.0 und 3.8 vermeiden. Während RHEL an den 2.6-Kerneln festgehalten hat (die ihre eigenen Probleme haben, aber nicht so schlimm sind), hat Ubuntu verschiedene 3.X-Kernel für 12.04 veröffentlicht ... ein Upgrade ... auf Kernel 3.13.0 durchgeführt und genau die gleiche Arbeitslast ausgeführt ... eine Reduzierung der E / A um 80%. Wir können den intelligenten Mitarbeitern der Linux FS / MM-Gruppe dafür danken, dass sie eine ganze Reihe von Leistungen erbracht haben Probleme."

Weitere Informationen finden Sie unter http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html

Adam Cassel
quelle
Oeh, interessant. Debian ist immer noch bei 3.2 im Stall, aber ich sehe einige neuere Kernel in Wheezy-Backports, ich werde sie bald überprüfen!
Wrikken
1

Ich habe im DBA StackExchange ein Problem mit dem Kernel und dem Journaling behoben . Ich habe dies bereits im Mai von Percona erfahren, dass ein bestimmtes Flush-Verhalten tatsächlich simuliert wird.

  • Möglicherweise müssen Sie die Art der Journalerstellung ändern.
  • Möglicherweise müssen Sie InnoDB optimieren
    • Lockern der ACID-Konformität für die Schreibleistung (Setzen von innodb_flush_log_at_trx_commit auf 0 oder 2)
    • Größere Protokolldateien
    • Größerer Protokollpuffer
RolandoMySQLDBA
quelle
Sehr interessante Lektüre, danke, insbesondere der verlinkte Artikel im MySQL-Performance-Blog . Ich werde das Dateisystem hier überprüfen, anscheinend haben sie Daten = derzeit bestellt.
Wrikken
0

Möglicherweise ist die gemeldete Last einfach nicht korrekt, wie in diesem Fehlerbericht: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693942

Kannst du sehen, dass es tatsächlich etwas langsameres gibt? oder sieht vmstat so aus, als würde der server wirklich mehr arbeiten? Andernfalls würde ich annehmen, dass Sie gerade diesen gemeldeten Fehler getroffen haben. Dasselbe ist mir vor einiger Zeit passiert. Die Leistung des Servers war nicht anders, nur der Durchschnitt der ausgegebenen Last war höher.

Wiederholung
quelle
0

Ich habe nicht den Ruf, dies zu kommentieren. Aber als Sie den Kernel aktualisiert haben, haben Sie auch die Version von MySQL aktualisiert? Können Sie auflisten, welches MySQL 5.5.X Sie ausführen?

Ironischerweise haben Fehler in einigen der neueren Versionen von MySQL die Leistung spürbar verschlechtert. Sie haben sie natürlich behoben, aber es hat bei den Änderungen in meiner App ein erhebliches rotes Gehör für mich verursacht.

"InnoDB: Das Update für Fehler # 17699331 verursachte eine hohe Rate an Lese- / Schreibsperren, die zu einer Leistungsregression führten (Bug # 18345645, Fehler # 71708)."

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-19.html

"InnoDB: Eine durch Bug # 14329288 eingeführte Regression würde zu einer Leistungsverschlechterung führen, wenn eine komprimierte Tabelle nicht in den Speicher passt. (Bug # 18124788, Bug # 71436)"

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-17.html

..usw

Für 5.5 ist es genauso:

"InnoDB: Eine durch Bug # 14329288 eingeführte Regression würde zu einer Leistungsverschlechterung führen, wenn eine komprimierte Tabelle nicht in den Speicher passt. (Bug # 18124788, Bug # 71436)"

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-37.html

Wird durch ein Upgrade auf ein neueres MySQL wieder eine angemessene Leistung erzielt?

MySQL enthält auch einen kernelspezifischen Code:

"In einigen Linux-Kernelversionen wird asynchrone E / A auf tmpfs nicht unterstützt. Die Problemumgehung bestand darin, die Einstellung innodb_use_native_aio zu deaktivieren oder ein anderes temporäres Verzeichnis zu verwenden. Der Fix bewirkt, dass InnoDB die Einstellung innodb_use_native_aio automatisch deaktiviert, wenn die temporäre Datei erkannt wird Verzeichnis unterstützt keine asynchrone E / A. (Fehler # 13593888, Fehler # 11765450, Fehler # 58421) "

" http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-5.html

Ich würde also sicherstellen, dass Sie den neuesten Build ausführen.

Nebenbei bemerkt, MySQL 5.6.X (das jetzt offiziell stabil ist und schon seit einiger Zeit): "Für Linux zeigt MySQL 5.6 eine bis zu 150% ige Verbesserung des TPS-Durchsatzes gegenüber MySQL 5.5" http: //dev.mysql. com / tech-resources / articles / mysql-5.6-rc.html

Matthew1471
quelle
-1

Ich hatte große Probleme mit der MySQL-Leistung, als ich von Debian mit Kernel 2.6 und MySQL 5.1 zu Debian mit Kernel 3.2 und MySQL 5.5 (keuchend) wechselte.

Was das Problem für MySQL löste, war Barriere = 0 in / etc / fstab. Überprüfen Sie https://wiki.archlinux.org/index.php/Ext4

Daniel
quelle
Barriere = 0 deaktiviert Barrieren und das bedeutet, dass Sie Daten verlieren können, wenn der Strom ausfällt oder etwas abstürzt.
Jure1873
@ Jure1873: hm, so wie ich es verstehe, ist es ziemlich sicher für batteriegepufferte Festplatten, und wer würde bei einer ernsthaften Datenbankkonfiguration darauf verzichten?
Wrikken
Nun, Sie sollten auf Nummer sicher gehen, wenn die Festplatten batteriegepuffert sind, aber ich gehe immer gerne auf Nummer sicher. Wenn es eine Kernel-Panik gibt oder etwas furchtbar schief geht, könnten Sie in Schwierigkeiten geraten.
Jure1873