App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hohe IO-Last durch MySQL in Verbindung mit neuem Kernel
- Ersteller Dalai
- Erstellt am
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Hallo Linux-Gemeinde,
ich hoffe, ihr könnt mir bei einem kuriosen Problem assistieren. Es geht um folgende Hardware:
AMD X2 BE-2300 auf GA-MA69G-S3H
Platte WD5003ABYX an SATA-Controller im AHCI-Modus
Auf dem System läuft ein MySQL 5.5.53 als Slave, der permanent die Daten des Master repliziert, was auch einwandfrei funktioniert. Das System wurde gestern von Ubuntu 12.04 auf 14.04 aktualisiert. Im Zuge dessen wurde natürlich auch der Kernel erneuert (3.8 auf 3.13). Leider hat sich herausgestellt, dass die IO-Last durch den MySQL (und zwar nur durch diesen) um Faktoren höher ist als vorher .
Um mal die Größenordnung zu verdeutlichen: Der MySQL war während des Systemupgrades für insgesamt 5 Stunden offline, wurde später gestartet und machte dann über eine Zeitspanne von ca. 1:10h volle IO-Last auf einem Kern mit nur 30 Queries/sec. Nachdem er damit fertig war, den Rückstand zum Master abzubauen, war die IO-Last trotzdem um Faktoren höher als üblich, was ich zum Anlass nahm, den MySQL-Slave über Nacht lahmzulegen.
Heute startete ich den Server mit dem alten Kernel 3.8. Nach insgesamt ~14 Stunden Offline-Zeit wurde der MySQL-Slave wieder gestartet - Ergebnis: der war in 40 Minuten mit der Replikation fertig und verursachte dabei ca. 15 % IO-Last mit über 110 Queries/sec. Ich hänge mal Bilder vom Munin an, damit sich die Kenner ein Bild der Lage machen können; die hohe IO-Last gestern ist ja nicht zu übersehen , die Replikation heute ist rechts (oben) im Graphen zu sehen.
Das Problem ist auch sofort reproduzierbar, d.h. ein simpler Reboot mit dem älteren Kernel lässt die Last sofort verschwinden, ein Boot mit dem neueren Kernel lässt sie sofort wieder auftauchen. Die Installation des neuesten HWE-Stacks mit Kernel 4.4 ändert nichts an der Situation.
Ein generelles Problem mit der SATA-Platte liegt nicht vor, wie auch die Ausgaben von fio zeigen - im Gegenteil sind eher die neueren Kernel etwas schneller.
Kernel 3.8:
Kernel 4.4:
Zusammenfassung:
Kann mir jemand einen Tip geben, wonach ich suchen kann, in welche Richtung? Irgendetwas, das man im MySQL umstellen kann? Ich weiß bei derartigen Problemstellungen, die nur bei Kombination von X mit Y auftauchen, noch nicht einmal, wonach ich suchen soll/könnte. "I'm completely lost" sozusagen .
Grüße
Dalai
ich hoffe, ihr könnt mir bei einem kuriosen Problem assistieren. Es geht um folgende Hardware:
AMD X2 BE-2300 auf GA-MA69G-S3H
Platte WD5003ABYX an SATA-Controller im AHCI-Modus
Auf dem System läuft ein MySQL 5.5.53 als Slave, der permanent die Daten des Master repliziert, was auch einwandfrei funktioniert. Das System wurde gestern von Ubuntu 12.04 auf 14.04 aktualisiert. Im Zuge dessen wurde natürlich auch der Kernel erneuert (3.8 auf 3.13). Leider hat sich herausgestellt, dass die IO-Last durch den MySQL (und zwar nur durch diesen) um Faktoren höher ist als vorher .
Um mal die Größenordnung zu verdeutlichen: Der MySQL war während des Systemupgrades für insgesamt 5 Stunden offline, wurde später gestartet und machte dann über eine Zeitspanne von ca. 1:10h volle IO-Last auf einem Kern mit nur 30 Queries/sec. Nachdem er damit fertig war, den Rückstand zum Master abzubauen, war die IO-Last trotzdem um Faktoren höher als üblich, was ich zum Anlass nahm, den MySQL-Slave über Nacht lahmzulegen.
Heute startete ich den Server mit dem alten Kernel 3.8. Nach insgesamt ~14 Stunden Offline-Zeit wurde der MySQL-Slave wieder gestartet - Ergebnis: der war in 40 Minuten mit der Replikation fertig und verursachte dabei ca. 15 % IO-Last mit über 110 Queries/sec. Ich hänge mal Bilder vom Munin an, damit sich die Kenner ein Bild der Lage machen können; die hohe IO-Last gestern ist ja nicht zu übersehen , die Replikation heute ist rechts (oben) im Graphen zu sehen.
Das Problem ist auch sofort reproduzierbar, d.h. ein simpler Reboot mit dem älteren Kernel lässt die Last sofort verschwinden, ein Boot mit dem neueren Kernel lässt sie sofort wieder auftauchen. Die Installation des neuesten HWE-Stacks mit Kernel 4.4 ändert nichts an der Situation.
Ein generelles Problem mit der SATA-Platte liegt nicht vor, wie auch die Ausgaben von fio zeigen - im Gegenteil sind eher die neueren Kernel etwas schneller.
Kernel 3.8:
Code:
$ fio --rw=randwrite --name=test --size=20M --direct=1
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 1 process
test: (groupid=0, jobs=1): err= 0: pid=3143: Tue Jan 17 17:54:10 2017
write: io=20480KB, bw=2833.5KB/s, iops=708, runt= 7228msec
clat (usec): min=119, max=332412, avg=1402.69, stdev=5153.15
lat (usec): min=120, max=332414, avg=1404.30, stdev=5153.16
clat percentiles (usec):
| 1.00th=[ 131], 5.00th=[ 139], 10.00th=[ 149], 20.00th=[ 151],
| 30.00th=[ 153], 40.00th=[ 157], 50.00th=[ 163], 60.00th=[ 1144],
| 70.00th=[ 1560], 80.00th=[ 2064], 90.00th=[ 2736], 95.00th=[ 4576],
| 99.00th=[10816], 99.50th=[12352], 99.90th=[16512], 99.95th=[27264],
| 99.99th=[333824]
bw (KB /s): min= 1854, max= 3724, per=97.99%, avg=2776.14, stdev=512.83
lat (usec) : 250=54.16%, 500=0.04%, 750=0.20%, 1000=1.25%
lat (msec) : 2=22.81%, 4=15.92%, 10=3.98%, 20=1.56%, 50=0.06%
lat (msec) : 500=0.02%
cpu : usr=0.61%, sys=2.66%, ctx=5124, majf=0, minf=28
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=5120/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=20480KB, aggrb=2833KB/s, minb=2833KB/s, maxb=2833KB/s, mint=7228msec, maxt=7228msec
Disk stats (read/write):
sdb: ios=0/4991, merge=0/4, ticks=0/8036, in_queue=8036, util=95.94%
Kernel 4.4:
Code:
$ fio --rw=randwrite --name=test --size=20M --direct=1
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 1 process
test: (groupid=0, jobs=1): err= 0: pid=14292: Tue Jan 17 17:48:48 2017
write: io=20480KB, bw=4621.2KB/s, iops=1155, runt= 4431msec
clat (usec): min=129, max=33217, avg=856.46, stdev=2017.90
lat (usec): min=131, max=33218, avg=858.06, stdev=2017.88
clat percentiles (usec):
| 1.00th=[ 139], 5.00th=[ 149], 10.00th=[ 157], 20.00th=[ 159],
| 30.00th=[ 163], 40.00th=[ 163], 50.00th=[ 165], 60.00th=[ 169],
| 70.00th=[ 175], 80.00th=[ 972], 90.00th=[ 2512], 95.00th=[ 4448],
| 99.00th=[ 9024], 99.50th=[12608], 99.90th=[21376], 99.95th=[23936],
| 99.99th=[33024]
bw (KB /s): min= 4047, max= 5625, per=97.64%, avg=4511.75, stdev=515.12
lat (usec) : 250=78.83%, 500=0.45%, 750=0.31%, 1000=0.62%
lat (msec) : 2=7.11%, 4=6.76%, 10=5.20%, 20=0.61%, 50=0.12%
cpu : usr=1.08%, sys=3.52%, ctx=5135, majf=0, minf=6
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=5120/d=0, short=r=0/w=0/d=0
Run status group 0 (all jobs):
WRITE: io=20480KB, aggrb=4621KB/s, minb=4621KB/s, maxb=4621KB/s, mint=4431msec, maxt=4431msec
Disk stats (read/write):
sdb: ios=0/5033, merge=0/0, ticks=0/4160, in_queue=4160, util=92.53%
Zusammenfassung:
- Problem vorhanden mit Kernel 3.13 und 4.4, aber nicht mit 3.8, ein simpler Reboot lässt die Last je nach Kernel erscheinen oder verschwinden.
- Der Master wird permanent mit Daten gefüttert. Das erfolgt mit konstanter Menge von Queries/sec, so dass das für das Problem also keine Rolle spielt.
- Konfiguration des MySQL ist unverändert, auf Master und Slave.
- Der Master lief die ganze Zeit über normal und hat kein Problem mit IO-Last, verwendet allerdings komplett andere Hardware.
Kann mir jemand einen Tip geben, wonach ich suchen kann, in welche Richtung? Irgendetwas, das man im MySQL umstellen kann? Ich weiß bei derartigen Problemstellungen, die nur bei Kombination von X mit Y auftauchen, noch nicht einmal, wonach ich suchen soll/könnte. "I'm completely lost" sozusagen .
Grüße
Dalai
Anhänge
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.611
- Renomée
- 427
- Standort
- Bayern, am Rande des Wahnsinns
- Aktuelle Projekte
- Dieses und jenes
- BOINC-Statistiken
- Mein Laptop
- HP EliteBook 840 G2, Elitebook 850 G3
- Prozessor
- Ryzen7 5800X3D
- Mainboard
- Asus TUF B550 Plus
- Kühlung
- BeQuiet DarkRock4
- Speicher
- 4x16GB DDR4-3200 Crucial
- Grafikprozessor
- XFX RX6700XT 12GB
- Display
- 2x HP X27i
- SSD
- NVMe: 970EVO 1TB, SATA: WD Blue 1TB, 870QVO 4TB, Acer RE100 4TB, 870QVO 8TB
- Optisches Laufwerk
- LG BluRay-Brenner
- Soundkarte
- Realtek ALC1200
- Gehäuse
- Fractal Define R5
- Netzteil
- Seasonic Focus 650W
- Tastatur
- Keychron K4
- Maus
- Logitech MX518
- Betriebssystem
- Win10 Pro/64, Linux 64bit (wechselnd)
- Webbrowser
- Primär: Firefox, sekundär: Wechselnd
- Internetanbindung
- ▼100 MBit ▲32 MBit
Wenn du dich per Konsole in die MySQL einlogst, was sagt "show status;" ?
Schon versucht das Loglevel für MySQL anzupassen bw. was sagt das Log jetzt?
Schon versucht das Loglevel für MySQL anzupassen bw. was sagt das Log jetzt?
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Ich wusste doch, dass ich was vergessen habe zu erwähnen... Derzeit ist das General Log deaktiviert (default eben). Das Errorlog ist völlig normal und bietet keinen Hinweis auf irgendeine Art von Problemen. Ist ja auch irgendwie logisch, denn der MySQL ist normal ansprechbar, verursacht eben nur ungewöhnlich hohe Last. Ein "SHOW SLAVE STATUS\G" mit neuem Kernel lässt erkennen, dass bei normaler Replikation (= kein Aufholen des Rückstands zum Master) die "Seconds_Behind_Master" zum Teil von 0 leicht ansteigen (bis 5 hab ich schon gesehen, kann aber auch mehr gewesen sein) und einige Sekunden später wieder zurückgehen; beim alten Kernel ist das nicht der Fall.
Also werd ich den Server wohl nochmal mit neuem Kernel booten, das General Log einschalten und schauen, ob der dort irgendwas relevantes reinschreibt. Gibt's im "show status;" irgendetwas, auf das ich besonders achten sollte? Sind immerhin über 300 Zeilen...
Grüße
Dalai
Also werd ich den Server wohl nochmal mit neuem Kernel booten, das General Log einschalten und schauen, ob der dort irgendwas relevantes reinschreibt. Gibt's im "show status;" irgendetwas, auf das ich besonders achten sollte? Sind immerhin über 300 Zeilen...
Grüße
Dalai
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Also das General Log bringt gar nichts. Dort werden nur die normalen Queries, Connects, Quits usw. protokolliert - ganz normal, wie man es erwarten würde. Ein "show status;" hab ich für Kernel 3.8 und 3.13 jeweils aufgezeichnet; es sind Unterschiede vorhanden, aber ich kann nicht wirklich etwas damit anfangen. Wäre gut, wenn mir jemand einen Richtungsweiser geben könnte, welche der dort verzeichneten Werte von Bedeutung sind.
Grüße
Dalai
Grüße
Dalai
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Ausgehend von der Vermutung, dass das Dateisystem eine Rolle spielt, weil auf dem Master ext4 eingesetzt wird, auf dem Slave aber ext3, haben wir gestern verschiedene Szenarien genauer beleuchtet. Hier ist das Ergebnis:
Die Vermutung war also nicht so ganz richtig, aber die Richtung hat uns auf die richtige Spur gebracht. Nach etwas Herumsuchen hat sich herausgestellt, dass hier ein Problem vorliegt, das schon seit Jahren im Web diskutiert wird . Beispiele:
[ubuntu] MySQL slow on ext4 - Karmic 64 bit?
MySQL :: MySQL is running 8,000% slower on CentOS 6x than CentOS 5x. Maybe ext4 related?
MySQL is VERY slow on my ext4 file system - Server Fault - mit Link zu einem Bugreport bei MySQL von 2009!
Effect of filesystems on MySQL performance
Internal Hard drive extremely slow unless using barrier=0 on ext4
Warum ist nun Kernel 3.8 so viel schneller mit ext3 als Kernel 3.13? Ganz einfach: 3.8 verwendet ein separates Modul für ext3, während bei neueren Kerneln alles über das ext4-Modul abgewickelt wird, offenbar inklusive der performancebremsenden fsync()s auch bei ext3.
Warum ist der Master nicht von der Problematik betroffen? Auch das lässt sich recht einfach erklären: Dort ist ein Hardware RAID im Einsatz mit einer LSI MegaRAID-Karte mit eigenem Speicher, die - so meine Vermutung - dafür sorgt, dass die ankommenden Daten zwischengespeichert werden, und das OS sofort weitermachen kann, ohne auf das Leeren des HDD-Cache warten zu müssen.
Red Hat fasst die write barriers im Storage Administration Guide ganz gut zusammen:
So, nun sind wir also vor die Wahl gestellt:
Grüße
Dalai
Kernel | Modul | Dateisystem | Gemountet als | Mountoptionen | IO-Last (%) | Bemerkung |
3.8 | ext3 | ext3 | ext3 | acl | 3 | |
3.13 | ext4 | ext3 | ext3 | acl | 25 | |
3.13 | ext4 | ext3 | ext4 | acl | 15 | |
3.13 | ext4 | ext4 | ext4 | acl | vermutlich 25 | |
3.13 | ext4 | ext3 | ext3 | acl, barrier=0 | 2 | |
3.13 | ext4 | ext3 | ext3 | acl | 4-5 | MySQL-Option innodb_flush_log_at_trx_commit=2 |
3.13 | ext4 | ext3 | ext4 | acl, data=journal | 10 | |
3.13 | ext4 | ext3 | ext4 | acl, data=journal | 2 | MySQL-Option innodb_flush_log_at_trx_commit=2 |
3.13 | ext4 | ext3 | ext3 | acl, data=journal | 3 | MySQL-Option innodb_flush_log_at_trx_commit=2 |
[ubuntu] MySQL slow on ext4 - Karmic 64 bit?
MySQL :: MySQL is running 8,000% slower on CentOS 6x than CentOS 5x. Maybe ext4 related?
MySQL is VERY slow on my ext4 file system - Server Fault - mit Link zu einem Bugreport bei MySQL von 2009!
Effect of filesystems on MySQL performance
Internal Hard drive extremely slow unless using barrier=0 on ext4
Warum ist nun Kernel 3.8 so viel schneller mit ext3 als Kernel 3.13? Ganz einfach: 3.8 verwendet ein separates Modul für ext3, während bei neueren Kerneln alles über das ext4-Modul abgewickelt wird, offenbar inklusive der performancebremsenden fsync()s auch bei ext3.
Warum ist der Master nicht von der Problematik betroffen? Auch das lässt sich recht einfach erklären: Dort ist ein Hardware RAID im Einsatz mit einer LSI MegaRAID-Karte mit eigenem Speicher, die - so meine Vermutung - dafür sorgt, dass die ankommenden Daten zwischengespeichert werden, und das OS sofort weitermachen kann, ohne auf das Leeren des HDD-Cache warten zu müssen.
Red Hat fasst die write barriers im Storage Administration Guide ganz gut zusammen:
Yeah, no shit, Sherlock! Genau das passiert bei MySQL, wie man auch obiger Tabelle entnehmen kann; das InnoDB-Log ist hier maßgeblich und sorgt allein(!) für 20 Prozentpunkte mehr Last, wenn es bei jedem Commit geschrieben und geflusht wird, wie es standardmäßig passiert.Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower.
So, nun sind wir also vor die Wahl gestellt:
- [Tabelle Zeile 1] entweder alten Kernel weiterfahren, was aber nur solange gut geht, wie das Dateisystem ext3 bleibt, weil es bei ext4 ein generelles Problem gibt, sofern die write barriers eingeschaltet sind
- [Tabelle Zeile 5] ext4 mit barrier=0 mounten und somit dasselbe Risiko eines Datenverlusts oder Dateisystemkorruption wie bei ext3 haben
- [Tabelle Zeile 6] MySQL durch die Option innodb_flush_log_at_trx_commit=2 dazu bringen, das InnoDB-Log nicht bei jedem Commit zu flushen sondern nur einmal pro Sekunde
Grüße
Dalai
Zuletzt bearbeitet:
Nicht schlecht, Sherlock Ich weiß selber wie aufwändig solche versteckten Ursachen herauszudestillieren sind. Toll, dass Du da draufgekommen bist.
Ich persönlich würde vermutlich beim alten Kernel bleiben ("never touch a running system"). Wenn ich das richtig verstanden habe steht die Maschine ja am Backend und kommt nicht mit dem offenen Web in Berührung. Insofern wären ja auch verschleppte Bugfixes egal wenn keiner drankommt.
Wie ist das, wenn Du ein ganz anderes FS nämst, z.B. btrfs? Das läuft doch sicherlich nicht über das ext4-Modul, oder doch?
Ich persönlich würde vermutlich beim alten Kernel bleiben ("never touch a running system"). Wenn ich das richtig verstanden habe steht die Maschine ja am Backend und kommt nicht mit dem offenen Web in Berührung. Insofern wären ja auch verschleppte Bugfixes egal wenn keiner drankommt.
Wie ist das, wenn Du ein ganz anderes FS nämst, z.B. btrfs? Das läuft doch sicherlich nicht über das ext4-Modul, oder doch?
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.611
- Renomée
- 427
- Standort
- Bayern, am Rande des Wahnsinns
- Aktuelle Projekte
- Dieses und jenes
- BOINC-Statistiken
- Mein Laptop
- HP EliteBook 840 G2, Elitebook 850 G3
- Prozessor
- Ryzen7 5800X3D
- Mainboard
- Asus TUF B550 Plus
- Kühlung
- BeQuiet DarkRock4
- Speicher
- 4x16GB DDR4-3200 Crucial
- Grafikprozessor
- XFX RX6700XT 12GB
- Display
- 2x HP X27i
- SSD
- NVMe: 970EVO 1TB, SATA: WD Blue 1TB, 870QVO 4TB, Acer RE100 4TB, 870QVO 8TB
- Optisches Laufwerk
- LG BluRay-Brenner
- Soundkarte
- Realtek ALC1200
- Gehäuse
- Fractal Define R5
- Netzteil
- Seasonic Focus 650W
- Tastatur
- Keychron K4
- Maus
- Logitech MX518
- Betriebssystem
- Win10 Pro/64, Linux 64bit (wechselnd)
- Webbrowser
- Primär: Firefox, sekundär: Wechselnd
- Internetanbindung
- ▼100 MBit ▲32 MBit
Hatte ein paar tage keinen Zugriff aufs Forum, aber du hast es ja selber gefunden.
Wenn der Slave vom öffentlichen Netz getrennt ist, würde ich zunächst auch auf dem alten Kernel bleiben, ansonsten würde ich zunächst Option 6 nehmen, hat geringen impact und man kann den neuen Kernel mitnehmen, bis man eine andere Lösung hat.
Filesystem wechseln wäre auch eine Möglichkeit, eventuell XFS, BTRFS würde ich persönlich aber noch nicht einsetzen in der Produktivumgebung.
Wenn der Slave vom öffentlichen Netz getrennt ist, würde ich zunächst auch auf dem alten Kernel bleiben, ansonsten würde ich zunächst Option 6 nehmen, hat geringen impact und man kann den neuen Kernel mitnehmen, bis man eine andere Lösung hat.
Filesystem wechseln wäre auch eine Möglichkeit, eventuell XFS, BTRFS würde ich persönlich aber noch nicht einsetzen in der Produktivumgebung.
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Die 3er Serie der Kernel ist insgesamt nicht bekannt für gute random IO Durchsätze.
Das hat sich bei der 4er Serie deutlich geändert, die ist da merklich schneller.
Also wenn dann auf einen 4er Kernel gehen.
nobarrier ist halt gefährlich ohne Battieriebackup beim write-back-cache der Platte....
Ich habe bei mir folgendes auf der mysql Platte des Slaves als Mountoptionen: rw,noatime,nodelalloc,data=journal
Damit konnte ich für innodb (ist eine mariadb) folgendes setzen, was den Durchsatz deutlich steigerte:
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_read_io_threads = 4
innodb_write_io_threads = 8
sync_binlog = 1
Edit:
BTRFS als COW Dateisystem ist für die Performance einer Datenbank tödlich, Riddler82.
Hier müssen alle IOs mindestens 2x geschrieben werden.
Wenn dann noch ein innodb-log dazu kommt wird insgesamt 4x geschrieben.
Das kann nicht schnell sein.
XFS sollte eigentlich super zur Mysql passen aber ext4 in der Version der 4er Kernelserie allerdings auch.
Das hat sich bei der 4er Serie deutlich geändert, die ist da merklich schneller.
Also wenn dann auf einen 4er Kernel gehen.
nobarrier ist halt gefährlich ohne Battieriebackup beim write-back-cache der Platte....
Ich habe bei mir folgendes auf der mysql Platte des Slaves als Mountoptionen: rw,noatime,nodelalloc,data=journal
Damit konnte ich für innodb (ist eine mariadb) folgendes setzen, was den Durchsatz deutlich steigerte:
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_read_io_threads = 4
innodb_write_io_threads = 8
sync_binlog = 1
Edit:
BTRFS als COW Dateisystem ist für die Performance einer Datenbank tödlich, Riddler82.
Hier müssen alle IOs mindestens 2x geschrieben werden.
Wenn dann noch ein innodb-log dazu kommt wird insgesamt 4x geschrieben.
Das kann nicht schnell sein.
XFS sollte eigentlich super zur Mysql passen aber ext4 in der Version der 4er Kernelserie allerdings auch.
Zuletzt bearbeitet:
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Einerseits wäre das die wohl einfachste Lösung, andererseits gibt's dann von AppArmor Meldungen wie diese beim Booten (weil der Kernel die genannten Funktionen nicht unterstützt):Ich persönlich würde vermutlich beim alten Kernel bleiben ("never touch a running system").
Code:
Warning from profile /usr/sbin/mysqld (/etc/apparmor.d/usr.sbin.mysqld) ptrace rules not enforced
Warning from profile /usr/sbin/mysqld (/etc/apparmor.d/usr.sbin.mysqld) signal rules not enforced
Im Normalfall nicht. Aber das System soll den Master im Fall eines Fehlers/Ausfalls desselben komplett ersetzen - inkl. Dovecot, Postfix und sonstiger Dienste mit Internetzugang.Wenn ich das richtig verstanden habe steht die Maschine ja am Backend und kommt nicht mit dem offenen Web in Berührung.
Keine Ahnung, wie stabil das in Ubuntu 14.04 ist. Ich bin da auch ziemlich deutsch und sage eher "Keine Experimente" . Wenn das nur eine separate Partition für MySQL beträfe, wäre das vielleicht eine Überlegung wert, aber da dort auch sonstige Daten des Unternehmens liegen...Wie ist das, wenn Du ein ganz anderes FS nämst, z.B. btrfs?
Das sicher nicht. Wer weiß, ob btrfs nicht eine ähnliche Funktion zum Flushen des HDD-Caches hat, und falls dem so ist, ob sie sich wie bei ext4 abschalten lässt?Das läuft doch sicherlich nicht über das ext4-Modul, oder doch?
Grüße
Dalai
Zuletzt bearbeitet:
- Mitglied seit
- 11.11.2001
- Beiträge
- 9.611
- Renomée
- 427
- Standort
- Bayern, am Rande des Wahnsinns
- Aktuelle Projekte
- Dieses und jenes
- BOINC-Statistiken
- Mein Laptop
- HP EliteBook 840 G2, Elitebook 850 G3
- Prozessor
- Ryzen7 5800X3D
- Mainboard
- Asus TUF B550 Plus
- Kühlung
- BeQuiet DarkRock4
- Speicher
- 4x16GB DDR4-3200 Crucial
- Grafikprozessor
- XFX RX6700XT 12GB
- Display
- 2x HP X27i
- SSD
- NVMe: 970EVO 1TB, SATA: WD Blue 1TB, 870QVO 4TB, Acer RE100 4TB, 870QVO 8TB
- Optisches Laufwerk
- LG BluRay-Brenner
- Soundkarte
- Realtek ALC1200
- Gehäuse
- Fractal Define R5
- Netzteil
- Seasonic Focus 650W
- Tastatur
- Keychron K4
- Maus
- Logitech MX518
- Betriebssystem
- Win10 Pro/64, Linux 64bit (wechselnd)
- Webbrowser
- Primär: Firefox, sekundär: Wechselnd
- Internetanbindung
- ▼100 MBit ▲32 MBit
BTRFS als COW Dateisystem ist für die Performance einer Datenbank tödlich, Riddler82.
Hier müssen alle IOs mindestens 2x geschrieben werden.
Wenn dann noch ein innodb-log dazu kommt wird insgesamt 4x geschrieben.
Das kann nicht schnell sein.
XFS sollte eigentlich super zur Mysql passen aber ext4 in der Version der 4er Kernelserie allerdings auch.
Von BTRFS hatte ich ja auch eher abgeraten, allerdings weil ich noch nicht von der Stabilität überzeugt bin, und XFS vorgeschlagen.
Dass btrfs auch noch schreibintensiver ist hatte ich dabei noch nichtmal auf dem Radar.
4er Kernel mit Ext4 wäre auch noch eine Option, nobarrier in keinem Fall.
Zeile 6 von Dalai ging ja schon stark in deine Richtung, tomturbo.
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Zweifelhaft.Das hat sich bei der 4er Serie deutlich geändert, die ist da merklich schneller.
Wir haben - wie bereits am Anfang erwähnt - Kernel 4.4 probiert und er verhält sich mit ext3 (gemountet als ext3) exakt genauso wie 3.13. Zugegeben haben wir damit kein ext4 getestet.Also wenn dann auf einen 4er Kernel gehen.
Ja, lese ich immer wieder, verstehe aber trotzdem nicht, wie groß die Relevanz dessen ist. ext3 kennt ebenfalls write barriers, sie sind aber standardmäßig aus, bei ext4 standardmäßig an. So wie ich das bisher sehe, ist das doch nur dann wichtig, wenn der Strom direkt am Server ausfällt oder er nicht durch eine USV gesichert ist. Da der natürlich in einem Rack eingebaut ist, kommt da auch kein Unbefugter ran. Und wie gesagt gibt's ne USV.nobarrier ist halt gefährlich ohne Battieriebackup beim write-back-cache der Platte....
OK, das schau ich mir mal noch an. Bisher ging ich davon aus, dass das Schreiben der Daten ins Journal für noch mehr Plattenschrubben sorgen würde.Ich habe bei mir folgendes auf der mysql Platte des Slaves als Mountoptionen: rw,noatime,nodelalloc,data=journal
Damit konnte ich für innodb (ist eine mariadb) folgendes setzen, was den Durchsatz deutlich steigerte:
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
skip-innodb_doublewrite
innodb_read_io_threads = 4
innodb_write_io_threads = 8
sync_binlog = 1
Grüße
Dalai
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
OK, das schau ich mir mal noch an. Bisher ging ich davon aus, dass das Schreiben der Daten ins Journal für noch mehr Plattenschrubben sorgen würde.
Folgende Überlegung war bei mir dabei ausschlaggebend.
Da innodb sowieso mittels "innodb_doublewrite" die Daten doppelt schreibt ging ich davon aus (bzw. hab es in einem Artikel zur Mysql-Performance gelesen), dass das ext4 hier effizienter arbeitet als mysql selbst.
Da ich davon aus ging, dass ext4 sich innerhalb seines "Codes" bewegt und mysql sich mit Systemcalls behelfen muss.
Ich hatte ebenfalls am Slave starke "seconds behind", die ich mir nicht erklären konnte, denn am Master war alles in Ordnung.....
Ich konnte mit data=journal also sowohl das flush_log_trx_commit abdrehen, da die Daten ja schon zumindest im ext4 Journal sind, alsauch das "innodb_double_write".
Ich werde aber noch weitere diesbezüglich Forschungen machen.
Die höchste Performance erreicht man glaube ich, wenn man das Journal auf ext4 abdreht aber dafür die mysql-Sicherheitsmechanismen (flush_log und double_write) wieder aufdreht.
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Ich hab die Optionen mal durchgesehen und zum Teil ausprobiert. Zwei Dinge bringen jeweils sehr starke Verbesserungen: innodb_flush_log_at_trx_commit (war mir ja bereits bekannt) und die Mountoption data=journal. Ich habe entsprechende Messwerte in der Tabelle oben nachgetragen; siehe die letzten drei Zeilen.
Interessantweise führt die Mountoption zu dieser Meldung im Syslog, wenn man es als ext4 mountet (nicht bei ext3)
Ein Binlog gibt's auf dem Slave keines, und es wäre wohl kontraproduktiv, das zusätzlich noch einzuschalten . Die Lesethreads entsprechen dem Default. Die Schreibthreads zu verdoppeln mag zwar bei schnellen Platten oder SSDs mehr bringen, aber für eine einzelne normale SATA-Platte wie in diesem Fall dürfte das entweder keine oder eher negative Auswirkungen auf die IO haben.
Ich glaub, ich werd den Test noch mit Kernel 4.4 wiederholen, zweifle aber daran, dass sich an den Messwerten viel ändert.
Grüße
Dalai
Interessantweise führt die Mountoption zu dieser Meldung im Syslog, wenn man es als ext4 mountet (nicht bei ext3)
Wenn ich das richtig verstehe, wird innodb_flush_method = O_DIRECT wohl keinen Effekt mehr haben; daher und weil die Last schon gering genug war, hab ich's auch nicht weiter probiert.EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support!
Ein Binlog gibt's auf dem Slave keines, und es wäre wohl kontraproduktiv, das zusätzlich noch einzuschalten . Die Lesethreads entsprechen dem Default. Die Schreibthreads zu verdoppeln mag zwar bei schnellen Platten oder SSDs mehr bringen, aber für eine einzelne normale SATA-Platte wie in diesem Fall dürfte das entweder keine oder eher negative Auswirkungen auf die IO haben.
Ich glaub, ich werd den Test noch mit Kernel 4.4 wiederholen, zweifle aber daran, dass sich an den Messwerten viel ändert.
Grüße
Dalai
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Bei neueren Kernel wird O_DIRECT auf O_DSYNC gemappt.
Von daher wird "immer das Richtige " verwendet.
Bei data=journal ist wesentlich, dass man mit skip_innodb_doublewrite ein doppeltes Schreiben der Daten seitens mysql verhindert, weil ja eh im Journal vorhanden.
Von daher wird "immer das Richtige " verwendet.
Bei data=journal ist wesentlich, dass man mit skip_innodb_doublewrite ein doppeltes Schreiben der Daten seitens mysql verhindert, weil ja eh im Journal vorhanden.
Dalai
Grand Admiral Special
- Mitglied seit
- 14.06.2004
- Beiträge
- 7.420
- Renomée
- 262
- Standort
- Meiningen, Thüringen
- Mein Laptop
- Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
- Prozessor
- AMD Ryzen 5 2600 (Pinnacle Ridge)
- Mainboard
- ASUS Prime X370-A
- Kühlung
- Noctua NH-U12S mit 1x NF-F12
- Speicher
- Crucial Ballistix Sport LT weiß (BLS2K8G4D32AESCK): 2x 8 GiB DDR4-3200 (CL16) @ 1,25V
- Grafikprozessor
- Zotac GeForce GTX 1060 6GB AMP Edition
- Display
- Dell U2410, 24 Zoll, IPS, 16:10
- SSD
- Samsung 850 Evo 250 GB
- HDD
- WD40EZRZ (WD Blue) 4000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
- Optisches Laufwerk
- Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
- Soundkarte
- Creative SoundBlaster Audigy 2 ZS PCI
- Gehäuse
- Lian Li PC-8NB Midi-Tower
- Netzteil
- Enermax EMP400AGT MaxPro 400W
- Betriebssystem
- Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
- Webbrowser
- Mozilla Firefox mit diversen Erweiterungen
- Verschiedenes
- 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)
Wie ich schon vermutet hatte, sind die IO-Lasten mit Kernel 4.4 nicht anders als mit 3.13 - auch wenn ich mit dem neuen nicht alle Kombinationen ausprobiert habe. Es läuft wohl darauf hinaus:
Meine Fresse, bei solchen Dingen frage ich mich, warum das nicht offensichtlicher/besser dokumentiert ist. Offenbar ist MySQL auf ext4 manchmal (oder häufig?) eine schlechte Kombination, bei der man oft Hand anlegen muss, um einerseits Lastprobleme zu verhindern und andererseits schlechte Performance des MySQL auszubügeln.
Naja, was soll's, nun läuft's ordentlich. Bei den o.g. Einstellungen kann man es wohl belassen, und die Last ist wie mit Kernel 3.8 (evtl. sogar minimal geringer). Danke an alle Beteiligten .
Grüße
Dalai
- Mountoption data=journal
- MySQL-Optionen innodb_flush_log_at_trx_commit=2 und skip-innodb_doublewrite
Meine Fresse, bei solchen Dingen frage ich mich, warum das nicht offensichtlicher/besser dokumentiert ist. Offenbar ist MySQL auf ext4 manchmal (oder häufig?) eine schlechte Kombination, bei der man oft Hand anlegen muss, um einerseits Lastprobleme zu verhindern und andererseits schlechte Performance des MySQL auszubügeln.
Naja, was soll's, nun läuft's ordentlich. Bei den o.g. Einstellungen kann man es wohl belassen, und die Last ist wie mit Kernel 3.8 (evtl. sogar minimal geringer). Danke an alle Beteiligten .
Grüße
Dalai
Ähnliche Themen
- Antworten
- 15
- Aufrufe
- 717
- Antworten
- 6
- Aufrufe
- 2K