Raid-1 unter Debian 7.5 ohne Last schon extrem langsam

[Mickey61]

Hallo Gemeinde,

vor wenigen Tagen bekam unsere Webseite einen neuen Server. Umzug der Seiten etc lief problemlos ab, aber von Anfang an fiel auf, dass selbst nur wenige User Online bereits eine hohe Auslastung des Servers (i7-3770, 32 GB, 2*3 TB in Raid-1, 1 SSD) verursachten. Im Vergleich zum bisherigen Server schafften selbst die hundertfache Menge User keine solche Last!

Last bei wenigen Usern schon avg 4-5, nach Auslagern der MySQL-Daten auf die SSD 2-3.

atop zeigt: md0 0% busy, die dazu gehörigen sdb und sdc 50-100% busy bei 1-1.5 MB/s Write. Die Platten sind synchron, die Hardware wurde vom Support getestet und für in Ordnung befunden. Die SSD erzeugt mit der Hauptlast durch die MySQL-Daten 0% busy.

Hat jemand eine Idee, woran der hohe busy-Status kommen kann? Logisch, dass durch die I/O-Belastung die CPU-Kerne ausgelastet werden, aber es ist kein dafür verantwortlicher Prozess zu finden. Der Apache begnügt sich mit 1-2%, der MySQL mit manchmal 4-5%, alles andere ist ruhig.

Die Scripte und Software sind identisch konfiguriert wie auf dem alten Server, der trotz kleinerer Hardware bei 100+ Usern noch genug Reserven besass.

Vielen Dank für jeden Tipp und falls weitere Infos gebraucht werden, einfach fragen.

Michael

Im Titel sollte es "Debian 7.6" heissen

 

[Rumo]

Da kann man nur raten.

Irgendwas interessantes im dmesg?

cat /proc/mdstat? Läuft da noch ein Sync?

smartctl -a?

Bei ext4 könnte auch noch lazy*init Schreibzugriffe verursachen, aber damit man davon was merkt, muss dann trotzdem bei den Platten was im argen liegen...

MySQL falsch konfiguriert? Viel RAM nutzt nichts wenn MySQL ihn nicht nutzen darf. Dann wäre md0 bzw. die Datenbank allerdings busy...

 

[yummycandy]

Das gute alte hdparm liefert auch noch eventuelle Hilfswerte.

 

[Mickey61]

AW: Raid-1 unter Debian 7.6 ohne Last schon extrem langsam

Hallo und Danke an euch beiden,

nun, die Raid-Platten sind Synchron, dmesg liefert absolut nichts, was auf ein HDD-Problem hindeutet, smartctl ist nicht verfügbar und hdparm:

# hdparm -v /dev/sdb

/dev/sdb:
multcount = 16 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 364801/255/63, sectors = 5860533168, start = 0

# hdparm -v /dev/sdc

/dev/sdc:
multcount = 16 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 364801/255/63, sectors = 5860533168, start = 0

Auch alles so, wie es sein sollte. md0 ist ja auch völlig gelangweilt, MySQL läuft bereits ohne Probleme auf der SSD (und die langweilt sich auch, zumal MySQL ausreichend RAM zugewiesen bekommen hat und lesend kaum mal auf die Platte zugreift, schreibend halt nur bei den Aktualisierungen).

Atop zeigt dies (bei geringster Auslastung):

PRC | sys 9m21s | user 54m23s | | | #proc 149 | | #trun 1 | #tslpi 202 | #tslpu 3 | | #zombie 1 | clones 389e3 | | | #exit 0 |
CPU | sys 5% | user 13% | | irq 0% | | | idle 657% | wait 126% | | | steal 0% | guest 0% | | avgf 1.76GHz | avgscal 51% |
cpu | sys 1% | user 4% | | irq 0% | | | idle 47% | cpu000 w 48% | | | steal 0% | guest 0% | | avgf 1.96GHz | avgscal 57% |
cpu | sys 1% | user 3% | | irq 0% | | | idle 70% | cpu001 w 26% | | | steal 0% | guest 0% | | avgf 1.86GHz | avgscal 54% |
cpu | sys 1% | user 2% | | irq 0% | | | idle 77% | cpu002 w 20% | | | steal 0% | guest 0% | | avgf 1.82GHz | avgscal 53% |
cpu | sys 1% | user 2% | | irq 0% | | | idle 82% | cpu003 w 16% | | | steal 0% | guest 0% | | avgf 1.78GHz | avgscal 52% |
cpu | sys 0% | user 1% | | irq 0% | | | idle 96% | cpu005 w 3% | | | steal 0% | guest 0% | | avgf 1.64GHz | avgscal 48% |
cpu | sys 0% | user 1% | | irq 0% | | | idle 94% | cpu006 w 5% | | | steal 0% | guest 0% | | avgf 1.66GHz | avgscal 48% |
cpu | sys 0% | user 0% | | irq 0% | | | idle 94% | cpu007 w 5% | | | steal 0% | guest 0% | | avgf 1.67GHz | avgscal 49% |
cpu | sys 0% | user 0% | | irq 0% | | | idle 96% | cpu004 w 3% | | | steal 0% | guest 0% | | avgf 1.65GHz | avgscal 48% |
CPL | avg1 3.08 | | avg5 3.11 | | avg15 3.19 | | | | csw 92456004 | | intr 73385e3 | | | | numcpu 8 |
MEM | tot 31.2G | | free 27.8G | cache 1.6G | | dirty 40.4M | buff 544.4M | | slab 545.1M | | | | | | |
SWP | tot 16.0G | | free 16.0G | | | | | | | | | | vmcom 5.4G | | vmlim 31.6G |
MDD | md0 | | busy 0% | read 299 | | write 0 | KiB/r 4 | | KiB/w 0 | MBr/s 0.00 | | MBw/s 0.00 | avq 0.00 | | avio 0.00 ms |
MDD | md1 | | busy 0% | read 278 | | write 1 | KiB/r 3 | | KiB/w 1 | MBr/s 0.00 | | MBw/s 0.00 | avq 0.00 | | avio 0.00 ms |
MDD | md2 | | busy 0% | read 152699 | | write 3513e4 | KiB/r 9 | | KiB/w 4 | MBr/s 0.03 | | MBw/s 2.78 | avq 0.00 | | avio 0.00 ms |
DSK | sdc | | busy 61% | read 62207 | | write 1237e4 | KiB/r 12 | | KiB/w 12 | MBr/s 0.01 | | MBw/s 2.78 | avq 133.02 | | avio 2.56 ms |
DSK | sdb | | busy 59% | read 59653 | | write 1256e4 | KiB/r 10 | | KiB/w 11 | MBr/s 0.01 | | MBw/s 2.78 | avq 131.30 | | avio 2.46 ms |
DSK | sda | | busy 0% | read 13007 | | write 215190 | KiB/r 18 | | KiB/w 18 | MBr/s 0.00 | | MBw/s 0.07 | avq 1.77 | | avio 0.34 ms |
NET | transport | tcpi 1469306 | | tcpo 1500107 | udpi 68700 | udpo 68766 | tcpao 48118 | | tcppo 136034 | tcprs 19949 | tcpie 15 | tcpor 16658 | | udpnp 1590 | udpip 0 |
NET | network | | ipi 1543926 | ipo 1580142 | | ipfrw 0 | deliv 1541e3 | | | | | | icmpi 1155 | | icmpo 2823 |
NET | eth0 0% | pcki 925222 | | pcko 956654 | si 27 Kbps | | so 84 Kbps | coll 0 | mlti 0 | | erri 0 | erro 0 | | drpi 0 | drpo 0 |
NET | lo ---- | pcki 623530 | | pcko 623530 | si 43 Kbps | | so 43 Kbps | coll 0 | mlti 0 | | erri 0 | erro 0 | | drpi 0 | drpo 0 |
*** system and process activity since boot ***

Auffallend: Ohne wirklich Action auf dem Server - es sind grad 4 User im Web) sind die physikalischen Platten mit >50% busy! Die zugehörigen md0..2 haben nichts zu tun. Und selbst wenn 3 MB/s geschrieben werden müssen, dann dürfte das kaum die Grenzen überschreiten.

Das System ist vor wenigen Tagen erst frisch installiert, auch der Datentransfer von Server zu Server lief auch noch unauffällig ab. Zu der Zeit wurden die Platten noch synchronisiert! Zuerst viel es dann auf, als ein simples apt-get install sieves länger brauchte als ich für's Mittagessen und Kaffee holen...

Grüße, Michael

Ergänzung (1. September 2014)

Ich bin's nochmal...

nachdem ich immer mehr mich auf die Suche nach evtl. für das Verhalten zuständige Prozesse machte, fiel mir u.a. auf, dass der Apache lt. atop zeitweise 160+ MB/10s in das Raid schreibt, was ich mir ja garnicht erklären kann.

Weiss jemand irgendein Tool, mit dem man herausfinden kann, welcher Prozess was in welche Dateien schreibt?

Grüße, Michael

Ergänzung (1. September 2014)

Inzwischen bin ich schon einen Schritt weiter: Das Journaling des ext4-Raids scheint der Übeltäter zu sein. Mit noatime, nodiratime, commit=60 konnte die Last schon auf ein Drittel reduziert werden. Dennoch sehe ich das als reine Workarounds an.

 

[Mickey61]

AW: Raid-1 unter Debian 7.6 ohne Last schon extrem langsam

Was ich inzwischen auch noch herausgefunden habe: An 512 / 4k liegt es auch nicht. Bei allen Platten und allen Partitionen wird "aligned" beim Check ausgegeben. Partitioniert wurde mit gpt. Stehe dem Ganzen also imer noch recht ratlos gegenüber.

 

[Rumo]

AW: Raid-1 unter Debian 7.6 ohne Last schon extrem langsam

Bei allen Platten und allen Partitionen wird "aligned" beim Check ausgegeben.

Das wird auch gerne mal ausgegeben wenn es nicht aligned ist... wenn die Platte nicht sagt welche Sektorgrößen sie tatsächlich hat, kann die Software da auch nichts checken. Schau einfach daß die Partitionen auf MiB-Grenzen (mehrfache von 2048 x 512b-Sektoren) starten, das passt für alle Geräte.

Aber es scheint doch eher so zu sein daß bei dir irgendwas ziemlich viel schreibt (Apache?)

Du kannst dir ja mal btrace / blktrace anschauen...

 

[Mickey61]

AW: Raid-1 unter Debian 7.6 ohne Last schon extrem langsam

D

Aber es scheint doch eher so zu sein daß bei dir irgendwas ziemlich viel schreibt (Apache?)

Du kannst dir ja mal btrace / blktrace anschauen...

Grad mal zum Stand der Dinge:

Nachdem ich ja vorher schon MySQL auf die SSD verlegt hatte, habe ich das mit den Apache-Logs (ausser der der virtual-hosts) auch gemacht und zu guter Letzt den Disk-Cache verdoppelt und den Intervall zum Flushen hochgesetzt. Interessanterweise lief heute Morgen ein Sync der zweiten Platte im Raid, wobei dieser eher mühelos 80 MB/s schaffte. Als das beendet war, ging die Load des Servers von nominal erst 8, später 4 (MySQL-Umstellung), dann 2 (Logs), dann 1 (sync) auf jetzt erwartete < 0.1 zurück.

Wäre jetzt eigentlich nur interessant zu wissen, was das für ein Hexenwerk ist... btrace zeigt auf den HDD kaum Aktivität, auf der SSD die erwartete Hauptaktivität durch den MySQL und sonst nichts auffallendes.

Jetzt werde ich (mit Ausnahme des Disk-Caches, da ja absolut genug RAM vorhanden ist) alles zurück bilden und schauen, ob der Effekt wieder eintritt. Wenn nicht, dann fange ich an kleine Geister im Server an zu glauben