InnoDB lahmt, außer auf Gentoo

[MisC]

Hi,

ich versuche herauszufinden warum InnoDB auf einigen Distributionen dermaßen lahm ist. Bin aber inzwischen ziemlich mit meinem Latein am Ende.

Zum Testen nutze ich aktuell:

time mysqlslap --no-defaults -a -i 100 -c 50 -e innodb

Hier die Laufzeiten:

	real	user	sys
Gentoo	2m38.815s	0m1.853s	0m2.476s
Fedora	7m10,230s	0m2,416s	0m3,778s
ClearLinux	12m55.050s	0m2.180s	0m3.494s
Debian	13m8,906s	0m3,336s	0m5,677s

Folgendes habe ich bereits getestet und ausgeschlossen:

• Die Distributionen habe ich zum testen auf die identische VM auf einem HDD Raid installiert
• Es wurde das selbe Dateisystem verwendet
• SELinux und AppArmor wurden deaktiviert
• Es wurden die Pakete der Distribution sowie von mariadb.org getestet
• Die MariaDB Konfiguration ist identisch
• Starten von Debian mit dem Gentoo Kernel hat nichts geändert
• MariaDB auf Debian selbst zu kompilieren hat nichts verbessert

Das Gentoo mit dem ich teste ist noch absolut unoptimiert, also einfach nur ein entpacktes stage3-hardened-nomultilib ohne angepasste compiler flags.

Gibt es evtl. eine Möglichkeit um zu sehen wie viel Zeit ein Prozess in unterschiedlichen Libs benutzt? Denn das wäre aktuell mein letzter Ansatzpunkt, dass irgendeine System-Lib die genutzt wird dermaßen lahm ist.

Oder hat evtl. noch jemand weitere Ideen?

Nachtrag:

• Es wird die identische VM genutzt inkl. Blockdevice.
• Es wurden verschiedene MariaDB Versionen getestet 10.3, 10.4 und 10.5.
• Es wurden verschiedene Kernel und Kernel-Versionen getestet.
• Es wurden verschiedene Dateisysteme getestet.
• Ein Gentoo im chroot auf einem Fedora bringt fast die gleiche Leistung wie ein gebootetes Gentoo.

Hostsystem: Intel Xeon E3-1220 v3, 16 GB Ram, 4x WD Red Pro
Virtualisierung: KVM, LVM auf einem Raid 10 (cache='none' io='native')

Ich installiere die Minimalkonfiguration + sshd es läuft also sonst nichts im Hintergrund. Einziger großer Unterschied ist hier im Prinzip systemd.

Das Dateisystem ist ein ext4 mit Standard Parametern von Gentoo, inzwischen lösche ich auch nur noch den Inhalt und erstelle kein neues da ich auch schon die Vermutung hatte, dass es damit zusammenhängt. Tut es aber nicht.

Aktuell habe ich keine Möglichkeit mit SSDs zu testen, evtl komme ich am Wochenende dazu. Percona werde ich auch nochmal testen. Da ein Gentoo im chroot schon wesentlich schneller läuft werde ich mich aber erstmal den System-Libs widmen.

 

[kachiri]

Wenn ich es richtig in Erinnerung habe, ist Gentoo eine extrem schlanke Distro die einem erfahrenen Nutzer volle Kontrolle bei der Einrichtung der Umgebung gibt. Debian z.B. ist das komplette Gegenteil. Da wird im Hintergrund einfach mehr laufen.
Bei Gentoo muss man gar nicht erst anfangen "nachzuoptimieren", weil da im Ur-Zustand quasi nichts ist, während bei anderen Distros meist mal mehr und mal weniger "Lasten" mitgebracht werden.

Mal abgesehen davon, dass die vorkompilierten Pakete sich von Distro zu Distro unterscheiden können

 

[konkretor]

Kannst du mal raus suchen welchen Pakete du von MarioDB benutzt? ist es jedes mal die identische Version?
Meine Erfahrungen sind hier gibts immer Unterschiede in der Distri.

Ich nutze seit Jahren nur noch https://www.percona.com/software/mysql-database/percona-server und habe damit SQL Cluster gebaut oder einzeln betrieben. Da gabs nicht solche Probleme

 

[Dalek]

Meine Vermutung wäre unterschiedliches IO Verhalten. Ich würde mal genau auf die Dateisystemoptionen schauen, es gibt da manche die erheblichen einfluss haben können. Wobei die Defaults eigentlich ok sein sollten, würde mich wundern wenn die Distros da sehr komische Sachen machen würden.

Wenn der Gentoo Kernel extrem neu ist könnte da eine Fsync Verbesserung drin sein. Keine Ahnung ob die einfach so aktiv ist, aber bessere Fsync Performance könnte einen sehr deutlichen Effekt haben.

Wenn die Performance eine Rolle spielt würde ich eine Datenbank heute auch nur noch auf SSDs installieren. Die Optimierung auf eine HDD ist nur begrenzt übertragbar zu einer SSD, es gibt Parameter die man da ganz anders tunen muss.

Und welches Dateisystem benutzt du denn da überhaupt?

 

[Sannyboy111985]

Angaben des Kernels und der FS Parameter wären sicher nicht verkehrt.
Auch Angaben zum verwendeten Host System wären nicht schlecht.

Habe das ganze mal als vergleich auf einem Debian LXC Container unter Proxmox laufen lassen, der LXC hat 1(!) Kern von einem Intel Cleron J3455 mit 786MB(!) RAM auf Intel SSD DC S4500 mit ZFS als Dateisystem.

dtmb@mariadb:~$ time mysqlslap --no-defaults -a -i 100 -c 50 -e innodb
Benchmark
        Running for engine innodb
        Average number of seconds to run all queries: 0.648 seconds
        Minimum number of seconds to run all queries: 0.499 seconds
        Maximum number of seconds to run all queries: 0.794 seconds
        Number of clients running queries: 50
        Average number of queries per client: 0


real    1m22.925s
user    0m3.167s
sys     0m5.081s
dtmb@mariadb:~$ uname -a
Linux mariadb 5.4.106-1-pve #1 SMP PVE 5.4.106-1 (Fri, 19 Mar 2021 11:08:47 +0100) x86_64 GNU/Linux

Für mehr Details kannst du "strace -c" verwenden statt time.

 

[GrumpyCat]

Wenn ich es richtig in Erinnerung habe, ist Gentoo eine extrem schlanke Distro die einem erfahrenen Nutzer volle Kontrolle bei der Einrichtung der Umgebung gibt. Debian z.B. ist das komplette Gegenteil. Da wird im Hintergrund einfach mehr laufen.

Also a) Debian ist ganz sicher eine der Distributionen, die einem recht große Freiheiten lässt - man kann ja sogar alles "from source" installieren wie unter Gentoo, wenn man zuviel Zeit hat - und b) spielt es gar keine Rolle, wieviele Prozesse im Hintergrund laufen, weil die alle idle sind und bestenfalls wenige MB RAM wegnehmen (davon ab laufen bei einem Server-Debian auch nur crond, systemd, getty und Konsorten, die bei Gentoo auch laufen werden).

Tippe auch auf unterschiedliche Kernel und vermutlich insbesondere, da das ganze in einer VM läuft, ggf. andere Schnittstellen in Sachen I/O, oder evtl. andere Settings auf dem Host. Da gibt's einige Dinge wie https://www.electricmonk.nl/log/2016/03/14/terrible-virtualbox-disk-performance/ , die großen Unterschied machen können. Welche Virtualisierung wird denn überhaupt benutzt?

 

[AncapDude]

Sehr interessant. Ich nutze nur Debian auf meiner Farm und es wäre schade, wenn ich wegen der Distri soviel Performance verschenken würde. Habe das gerade mal auf einem der Hotspare Server (Idle) laufen lassen.

real    0m57.417s
user    0m2.514s
sys     0m3.043s
Linux 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-5+deb10u2~bpo9+1 (2019-08-16) x86_64 GNU/Linux

Maschine (dediziert): Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, DB auf nvme SW-Raid 1 (SAMSUNG MZVLB1T0HALR-00000), FS: /dev/md3 on / type ext4 (rw,relatime)

2. Maschine (Idle): Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, DB auf SATA-SSD SW-Raid 1 (Micron_M600_MTFDDAK512MBF), FS: /dev/md2 on / type ext4 (rw,relatime,stripe=256,data=ordered)

real    2m16,576s
user    0m3,516s
sys     0m3,004s
Linux 4.9.0-14-amd64 #1 SMP Debian 4.9.240-2 (2020-10-30) x86_64 GNU/Linux

 

[MisC]

Habe oben mal einiges ergänzt. Da ich es aktuell nicht auf SSDs testen kann und offenbar schon ein chroot mit Gentoo ausreicht, wäre es cool wenn die, die hier schon eigene Tests gepostet haben es mal damit probieren könnten.

 

[GrumpyCat]

Welche libc wird denn bei Dir unter Gentoo benutzt? Kannst auch mal ldd auf die mysql-Binary loslassen.

 

[Dalek]

Nachdem ich es mir mit den zusätzlichen Details nochmal angesehen habe würde ich auf ein Problem mit den VMs tippen. Die Unterschiede sind einfach zu groß, und schlechte storage performance ist etwas was bei bestimmten VM Konfigurationen auttreten kann. Ich würde das entweder mal auf echter Hardware ohne Virtualisierung ausprobieren, oder bei einem Anbieter einfach vServer kurz mieten da die vermutlich eine robustere Konfiguration da haben.

 

[snaxilian]

+1 für strace, damit siehst du jeden aber auch wirklich jeden Syscall

 

[RalphS]

Die größten Ecken und Kanten, die ich bei mir bisher so gefunden und behoben habe:
=> Blockgröße DBMS und Dateisystem müssen zusammenpassen
=> Virtualisiertes Dateisystem: Immer schlecht; besser ondisk oder als Dateisystemimage (wenn absolut nötig) und dann auf dem Vhost den Dateisystemcache aus
=> RAID Konfigurationen kosten ein bißchen Performance
=> Optimierungsarbeit an der SQL-Serverkonfiguration (passend aufs Hostsystem) hilft etwas, aber meist nicht besonders viel.

Allererster Vorschlag wäre zunächst, den Datenbankserver nativ zu installieren. Mit ZFS war bei mir ein dediziertes dataset erforderlich (blocksize=32k) damit das Ganze performant lief.

Ansonsten kenn ich ja jetzt die genauen Umstände nicht, aber störrische Indices, fehlende Indices, ungepflegte Indices ebenso wie überzählige Indices können genauso Performance fressen wie ungünstige Abfragen und stellenweise sogar fehlende Transaktionskapselungen.

Daß die Datendateien auf SSD gehören sollte sich hoffentlich von selber verstehen.

 

[GrumpyCat]

@RalphS Es geht doch hier gar nicht darum, die Performance an sich zu optimieren, sondern zu verstehen, warum MySQL bei einigen Distributionen bei ansonsten gleichen Parametern anscheinend so langsam ist.

 

[RalphS]

Und mir geht es darum, Anhaltspunkte zu präsentieren, wo man genau deswegen nachschauen kann.

An MySQL liegts in 9 von 10 Fällen nicht. Das Problem ist "normalerweise" ein Zusammenspiel.

 

[lokon]

Ein Haswell-Xeon mit VM und HDD Raid - da könnten auch Einstellungen der Spectre-Mitigation - deaktivieren dieser und andere Benchmarks zwischen den Distris interessant sein.

Ist das Verhalten der VM/Distris bei einfacheren Benchmarks (openssl, fio, dd, iperf, und andere (cpu, speicher) - zB aus phoronix test suite) denn gleich ?

 

[MisC]

Nach dutzenden Tests über das Wochenende mit und ohne VM, auf anderer Hardware sowie mit HDDs und SSDs ohne Auffälligkeiten, habe ich nun nochmal auf der eigentlichen Test-VM getestet und kann die ursprünglichen Ergebnisse nicht mehr reproduzieren. Es bleibt also ein Rätsel was da los war. An der Distribution liegt es offenbar nicht.

Jedenfalls Danke für eure Hilfe.

 

[snaxilian]

Hatte die ursprüngliche Test-VM zufällig ext3/4 als Dateisystem? Afaik ist da inzwischen die lazy initialization der Standard bzw. je nach gesetzten Flags beim kompilieren. Das führt dazu, dass Benchmarks verfälscht werden wenn diese zeitnah nach Anlage des Dateisystem durchgeführt werden.
https://www.thomas-krenn.com/de/wiki/Ext4_Dateisystem