Hohe IO-Last durch MySQL in Verbindung mit neuem Kernel

Dalai

Grand Admiral Special
Mitglied seit
14.06.2004
Beiträge
7.420
Renomée
262
Standort
Meiningen, Thüringen
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 *suspect*.

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 ;D, 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

  • cpu-day [2017-01-17].png
    cpu-day [2017-01-17].png
    20,6 KB · Aufrufe: 29
  • mysql_queries-day [2017-01-17].png
    mysql_queries-day [2017-01-17].png
    19,7 KB · Aufrufe: 29
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?
 
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 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
 
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:
KernelModulDateisystemGemountet alsMountoptionenIO-Last (%)Bemerkung
3.8ext3ext3ext3acl3
3.13ext4ext3ext3acl25
3.13ext4ext3ext4acl15
3.13ext4ext4ext4aclvermutlich 25
3.13ext4ext3ext3acl, barrier=02
3.13ext4ext3ext3acl4-5MySQL-Option innodb_flush_log_at_trx_commit=2
3.13ext4ext3ext4acl, data=journal10
3.13ext4ext3ext4acl, data=journal2MySQL-Option innodb_flush_log_at_trx_commit=2
3.13ext4ext3ext3acl, data=journal3MySQL-Option innodb_flush_log_at_trx_commit=2
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 8-(. 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:
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.
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.

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
Für welche Option würdet ihr euch entscheiden? Übrigens hängen beide Server an je einer USV, so dass Stromausfall keine Rolle spielt; das einzige, was man berücksichtigen müsste, wären Leute, die (un)absichtlich Stromkabel ziehen...

Grüße
Dalai
 
Zuletzt bearbeitet:
Nicht schlecht, Sherlock *great* Ich weiß selber wie aufwändig solche versteckten Ursachen herauszudestillieren sind. Toll, dass Du da draufgekommen bist. :D

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?
 
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.
 
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.
 
Zuletzt bearbeitet:
Ich persönlich würde vermutlich beim alten Kernel bleiben ("never touch a running system").
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):
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
Die kommen für jeden Dienst, der ein AppArmor-Profil hat (MySQL, Slapd, Named, und vielleicht noch mehr). Wie es aussieht, sind diese zwar nicht gravierend und können vorerst ignoriert werden, aber wer weiß, ob die nicht wichtig werden.

Wenn ich das richtig verstanden habe steht die Maschine ja am Backend und kommt nicht mit dem offenen Web in Berührung.
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.

Wie ist das, wenn Du ein ganz anderes FS nämst, z.B. btrfs?
Keine Ahnung, wie stabil das in Ubuntu 14.04 ist. Ich bin da auch ziemlich deutsch und sage eher "Keine Experimente" ;D. 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...

Das läuft doch sicherlich nicht über das ext4-Modul, oder doch?
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?

Grüße
Dalai
 
Zuletzt bearbeitet:
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.
 
Das hat sich bei der 4er Serie deutlich geändert, die ist da merklich schneller.
Zweifelhaft.

Also wenn dann auf einen 4er Kernel gehen.
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.

nobarrier ist halt gefährlich ohne Battieriebackup beim write-back-cache der Platte....
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.

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
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.

Grüße
Dalai
 
Ich schrieb ja nicht umsonst "z.B. btrfs". Der Hintergedanke war nur, herauszufinden, ob das Verhalten auf einem neueren Kernel mit einem non-ext-FS verschwindet oder nicht.
 
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.
 
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)
EXT4-fs: Warning: mounting with data=journal disables delayed allocation and O_DIRECT support!
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.

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
 
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.
 
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:
  • Mountoption data=journal
  • MySQL-Optionen innodb_flush_log_at_trx_commit=2 und skip-innodb_doublewrite
Das Abschalten des innodb_doubewrite brachte nochmal einen Prozentpunkt weniger Last auf dem fraglichen System.

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 *great*.

Grüße
Dalai
 
Zurück
Oben Unten