You are here
Wie verhält sich Galera Cluster mit vielen Knoten?
Fri, 2025-01-24 17:29 — oli
Kürzlich hatte ich die Gelegenheit ganz viele Linux Systeme (VMs mit Rocky Linux 9) aus einer unserer regelmässig stattfindenden Galera Cluster Schulungen eine Woche lang ganz für mich alleine zur freien Verfügung zu haben. Und auf den Maschinen war auch schon ein MariaDB 11.4.4 mit Galera Cluster installiert.
Da ich schon lange mal ausprobieren wollte, wie sich ein Galera Cluster mit zunehmender Anzahl Knoten verhält, war jetzt die Gelegenheit dies mal auszuprobieren.
Die folgenden Fragestellung sollten beantwortet werden:
- Wie verhält sich der Durchsatz eines Galera Clusters in Abhängigkeit der Anzahl Galera-Knoten?
- Mit welcher Konfiguration erhalten wir den grössten Durchsatz?
Insgesamt wurde mit 5 verschiedenen Versuchs-Parameter experimentiert:
- Anzahl Galera Knoten.
- Anzahl Client Maschinen (= Instanzen).
- Anzahl Threads pro Client (
--threads=). - Anzahl Galera Threads (
wsrep_slave_threads). - Laufzeit der Tests. Dieser Parameter wurde variiert weil einige Tests während des Laufs abgebrochen sind. Möglicherweise kann mit einer kleineren Rate (
--rate) im Lasttest dieser Parameter eliminiert werden. Wie sich zeigte, hatte er sehr wohl einen Einfluss auf das Resultat bzw. den gemessenen Durchsatz (z.B. Test 4b und 5 bzw. 18 und 19).
Insgesamt wurde 35 verschiedene Tests gefahren. Siehe Rohdaten.
Durchsatz in Abhängigkeit der Anzahl Galera Knoten
| Test | # gal nodes | # threads/client | runtime [s] | tps | runtime [s] |
|---|---|---|---|---|---|
| 7 | 1 | 8 | 180 | 596.3 | 180 |
| 8 | 2 | 8 | 180 | 567.8 | 180 |
| 9 | 3 | 8 | 180 | 531.9 | 180 |
| 11 | 4 | 8 | 180 | 495.2 | 180 |
| 12 | 5 | 8 | 180 | 492.2 | 180 |
| 13 | 6 | 8 | 180 | 502.9 | 180 |
| 14 | 7 | 8 | 180 | 459.5 | 180 |
| 15 | 8 | 8 | 180 | 458.6 | 180 |
| 16 | 9 | 8 | 180 | 429.2 | 180 |
Der Durchsatz im Galera Cluster nahm leicht von 600 tps auf 430 tps ab (28%) wenn die Anzahl Knoten von 1 auf 9 erhöht wurde.
Durchsatz in Abhängigkeit der Anzahl Verbindungen
Hier wurde vor allem mit der Anzahl der Clients und der Threads pro Client variiert. Bei 30 - 40 Connections scheint in diesem Setup das Optimum zu liegen. Das variieren der Anzahl Galera Threads (wsrep_slave_threads) scheint in unserem Fall nicht sonderlich viel bewirkt zu haben. Wesentlich mehr als 1200 tps scheint das System nicht herzugeben. Insbesondere haben auch die Maschinen der beschriebene Galera Knoten nicht mehr allzu viel CPU Idle Zeit gehabt.
| Test | # client nodes | # threads/client | # con tot | # gal threads | runtime [s] | tps |
|---|---|---|---|---|---|---|
| 16 | 1 | 8 | 8 | 1 | 180 | 429.2 |
| 17 | 2 | 8 | 16 | 1 | 180 | 684.5 |
| 18 | 3 | 8 | 24 | 1 | 180 | 603.8 |
| 19 | 3 | 8 | 24 | 1 | 120 | 925.2 |
| 20 | 3 | 8 | 24 | 1 | 120 | 919.8 |
| 21 | 4 | 8 | 32 | 1 | 120 | 1081.1 |
| 22 | 5 | 8 | 40 | 1 | 120 | 1196.0 |
| 23 | 5 | 8 | 40 | 4 | 120 | 1132.2 |
| 23b | 5 | 8 | 40 | 8 | 120 | 1106.0 |
| 24 | 5 | 16 | 80 | 4 | 120 | 1233.8 |
| 25 | 5 | 32 | 160 | 4 | 120 | 1095.7 |
Durchsatz in Abhängigkeit aller möglichen Parametern
Mit dem weiteren Variieren der Parameter insbesondere dem Reduzieren der Anzahl Galera Knoten von 9 auf 3 konnte der Durchsatz von knapp unter 1200 auf knapp über 1400 tps weiter erhöht werden.
| Test | # gal nodes | # client nodes | # threads/client | # con tot | tps |
|---|---|---|---|---|---|
| 23 | 9 | 5 | 8 | 40 | 1132.2 |
| 23b | 9 | 5 | 8 | 40 | 1106.0 |
| 24 | 9 | 5 | 16 | 80 | 1233.8 |
| 25 | 9 | 5 | 32 | 160 | 1095.7 |
| 26 | 8 | 5 | 32 | 160 | 1132.4 |
| 27 | 7 | 5 | 32 | 160 | 1207.6 |
| 28 | 6 | 5 | 16 | 80 | 1333.3 |
| 29 | 5 | 5 | 8 | 40 | 1278.6 |
| 30 | 5 | 5 | 8 | 40 | 1281.5 |
| 31 | 4 | 5 | 8 | 40 | 1374.1 |
| 32 | 3 | 5 | 8 | 40 | 1304.3 |
| 33 | 3 | 6 | 8 | 48 | 1428.9 |
Es scheint also, mit gegebener Hardware irgendwo ein Optimum zu geben welches sich um 3 Galera Knoten und ca 40 Connections befindet. Genauere Abklärungen wären hier spannend...
Statistische Versuchsplanung / Design of Experiments (DoE)
Hier wäre es noch spannend mit der Methode der statistischen Versuchsplanung zu arbeiten um dieses Optimum genauer zu bestimmen bzw. schneller zu finden.
- Mettler Toledo: DoE - Statistische Versuchsplanung - Ein statistischer Ansatz zur Reaktionsoptimierung.
- Wikipedia.de: Statistische Versuchsplanung.
- Versuchsplanung - DoE - Design of Experiments.
- Novustat: Quality Engineering: Statistische Versuchsplanung – Unser ultimativer Überblick!.
Harware Spezifikation
VM's von Hetzner: CX22 (2 vCPU, 4 Gibyte RAM (effektiv: 3.5 Gibyte (warum das?)), 40 Gibyte Disk)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 40 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
BIOS Vendor ID: QEMU
Model name: Intel Xeon Processor (Skylake, IBRS, no TSX)
BIOS Model name: NotSpecified
CPU family: 6
Model: 85
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 4
BogoMIPS: 4589.21
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2a
pic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault pti ssbd ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap clwb avx512cd avx512bw avx512vl xs
aveopt xsavec xgetbv1 xsaves arat pku ospke md_clear
Virtualization features:
Hypervisor vendor: KVM
Virtualization type: full
Caches (sum of all):
L1d: 64 KiB (2 instances)
L1i: 64 KiB (2 instances)
L2: 8 MiB (2 instances)
L3: 16 MiB (1 instance)
Benchmark-Tool / Last-Generator
Als Last-Generator wurde sysbench verwendet.
# dnf install epel-release # dnf install sysbench
Jeder Client läuft auf seinem eigenen Schema um Galera Cluster Konflikte zu vermeiden. Dies ist in der Realität nicht in jedem Fall gegeben, stellt aber für Galera den optimalen Fall dar.
SQL> CREATE DATABASE sbtest<n>;
Jeder Client verbindet sich auf einen anderen Galera Knoten (1 - 6 Clients verteilt auf 1 - 9 Galera Knoten).
GALERA_IP=<galera_ip>
DATABASE=sbtest<n>
# sysbench oltp_common --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --db-driver=mysql prepare
# sysbench oltp_read_write --time=180 --db-driver=mysql --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --threads=8 --rate=1000 --report-interval=1 run
# sysbench oltp_common --mysql-host=${GALERA_IP} --mysql-user=app --mysql-password=secret --mysql-db=${DATABASE} --db-driver=mysql cleanup
MariaDB und Galera Konfiguration
[server] binlog_format = row innodb_autoinc_lock_mode = 2 innodb_flush_log_at_trx_commit = 2 query_cache_size = 0 query_cache_type = 0 wsrep_on = on wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so wsrep_cluster_address = "gcomm://10.0.0.2,10.0.0.3,10.0.0.4,10.0.0.5,10.0.0.6,10.0.0.7,10.0.0.8,10.0.0.9,10.0.0.10,10.0.0.11,10.0.0.12,10.0.0.13,10.0.0.14,10.0.0.15,10.0.0.16,10.0.0.17" wsrep_cluster_name = 'Galera Cluster' wsrep_node_address = 10.0.0.2 wsrep_sst_method = rsync wsrep_sst_auth = sst:secret
Rohdaten
Taxonomy upgrade extras: