Auslastung des Systems beurteilen

[Exxter]

Hallo,

ich habe einen Debian Stretch 64bit Server bei Hetzner auf dem einige Dienste laufen: OTRS 5 (MariaDB), Nextcloud 13 (MariaDB), ein Jave-Webinterface (MariaDB), LDAP, Apache, MariaDB, Postfix und eine KVM VM mit Debian Jessie, die allerdings "load average: 0.00, 0.00, 0.00" hat. Alle Software ist aktuell gehalten. Hier die Ausgabe vom htop auf dem Host:

gallery/image/1785

Ich verstehe aber nicht so recht, was den Server so auslastet: die Festplatten (eine TOSHIBA DT01ACA300 und eine Seagate Barracuda ST33000651AS, jeweils mit 3TB, 7200 rpm, Sata 6 als RAID), hat scheinbar nichts zu tun (DISK R/W), hat nie MB, immer nur K/s, sollte eine Festplatte nicht auslasten. Die 8 Kerne der CPU (Intel i7-3770) langweilen sich, und der RAM (16GB) wird nicht voll genutzt bzw. ist alles andere als am Anschlag.

Trotzdem reagieren die Web-Interfaces sehr träge. Auf einem identischen Server reagieren sie deutlich flüssiger - ok, dort greifen nicht so viele Leute zu. Auf obigen Server greifen zwischen 20 - 30 User gleichzeitig zu.

Zu erwähnen ist außerdem, dass ein DRBD alle Daten (/home, /daten mit libvirt, ldap, mysql, /opt/ und /var/www) außer das Debian selbst über eine 1GB/s Leitung auf einen identischen zweiten Server synchronisiert.

Jemand eine Idee, woher der hohe Load kommt? Eigentlich ist der Server, nach meiner Einschätzung, schon recht potent - sollte für die paar Anwendungen doch völlig reichen?

[Lord_Carlos]

Nur weil nicht viele MB/s von der Festplatte gelesen wird heist es nicht das die nicht ausgelastet wird.
Such mal nach "IOwait"
Ich glaube atop zeigt es dir an, aber vielleicht gibt es noch was besseres.

[whisper]

Genau iotop
Und für mariadb hast du die Config optimiert?
Da du mehr als genug RAM hast, solltest du das für die Datenbank nutzen.
(https://github.com/RootService/tuning-primer)

[Exxter]

Hallo,

vielen Dank für die Tipps! Ich habe mal Screenshots gemacht:

atop:
gallery/image/1787

iotop (wechselt ständig, ist ungefähr der Durchschnitt):
gallery/image/1786

iotop ist noch nachvollziehbar, aber bei atop sehe ich nicht durch was da was ist. Am Ende könnte doch die Festplatte der Flaschenhals sein? Aber mir kommt das trotzdem nicht viel vor, können Festplatten nicht 40MB/s oder sowas in der Richtung lesen und schreiben? Obwohl da natürlich auch wieder die Sache ist, je mehr der Kopf der Festplatte hin und her fahren muss, desto langsamer wird alles.

Wegen MariaDB und RAM-Optimierungen, das schaue ich mir gleich an.

[whisper]

Wegen dem enormen jdb2 I/O: (80%)
läuft da noch ein Sync; Raid1 rebuild oder ist dein Server Sysnc das Problem?

[Exxter]

Ja, ein sync von drbd läuft noch:



Sollte der wirklich so viel Last erzeugen mit 632K/s?

[Lord_Carlos]

iotop ist noch nachvollziehbar, aber bei atop sehe ich nicht durch was da was ist. Am Ende könnte doch die Festplatte der Flaschenhals sein? Aber mir kommt das trotzdem nicht viel vor, können Festplatten nicht 40MB/s oder sowas in der Richtung lesen und schreiben? Obwohl da natürlich auch wieder die Sache ist, je mehr der Kopf der Festplatte hin und her fahren muss, desto langsamer wird alles.

Laut atop ist eine deiner Festplatten zu 55% ausgelastet. Aber ich kann nicht genau sagen wie atop dies ausrechnet.

Deine Festplatte kann sicherlich auch 150MB/s lesen/schreiben, aber halt nicht random IO.
Selbst verglichen mit anderen Festplatten der art ist diene Seagate nicht so pralle: http://www.storagereview.com/seagate_3t ... 33000651as

SSD ist liebe, SSD ist leben.

Ich weis nicht was ein DRBD ist, aber daran kann es nicht liegen? Also das dies IO irgendwie blocked?

[whisper]

Naja, den reinen Zahlen nach sieht es nicht so aus, aber es wird besser sein, wenn das erledigt ist.
Das ist doch ein Sync über das Netz, damit dürfte der Enpass zu erklären sein, das sind doch Kernel IO, die in der anderen Zeit nicht die restlichen I/O Aufgaben abarbeiten können.
Siehe deinem ersten Screenshot, der BLAU Anteil, das sollte IO/-Wait sein.
Habe hier gerade kein Linux sonst könnte ich mal genauer gucken

[heisenberg]

Ich weis nicht was ein DRBD ist, aber daran kann es nicht liegen? Also das dies IO irgendwie blocked?

DRBD ist ein RAID-1 über Netzwerk. Beim empfohlenen Modus "vollsynchron" gilt der Datenblock als geschrieben, wenn der aktive Knoten und der replizierte Knoten die Daten tatsächlich auf die Festplatte geschrieben haben. Das erhöht die Latenz also schon deutlich, weil die Daten eben noch mal zusätzlich über das Netzwerk gehen müssen. Also gerade für Datenbanken ist das schon eine gewisse Bremse.

[MSfree]

können Festplatten nicht 40MB/s oder sowas in der Richtung lesen und schreiben?

Lineares lesen bzw. schreiben geht in der Regel sogar noch schneller.

Allerdings können typische Festplatten mit 7200U/min nur 120 Spurwechsel pro Sekunde durchführen. Die Blockgröße moderner Festplate liegt bei 4kB, so daß die theoretisch langsamste Datenrate, die erreichbar ist, nur 480kByte/s beträgt.

[Exxter]

Also der Sync ist über Nacht fertig geworden, jetzt zeigt atop bei sda einen Wert zwischen 35% und 40% Auslastung an. Die Webinterfaces reagieren wieder flüssiger. Hier wird immer mehr sichtbar, dass die Festplatten an ihre Grenzen kommen. Ihr habt aber auch Recht, ich werde MariaDB optimieren und dann, wenn möglich die DB über Galera synchronisieren lassen.

Danke euch!

[Lord_Carlos]

Vielleicht auch ne guenstige SSD kaufen?
Wenn du der nicht ganz vertraust dann vielleicht nur als LVM cache drive?

[Exxter]

Das ist bei gemieteten Root-Servern (Hetzner) glaub ich nicht so einfach (zumindest hab ich das noch nie gemacht). Aber ich mach mich mal schlau was das kosten würde, aber erstmal checke ich die Möglichkeiten die ich noch habe mit optimieren.

[heisenberg]

Du kannst das Protokoll von DRBD ja mal testweise von C (vollsynchron) auf A (umkonfigurieren). Dann siehst Du, ob sich das gefühlt von der Last verändert. Das geht afaik aber nur in der Konfigurationsdatei von DRBD. D. h. da musst Du kurz alles offline nehmen.

Da gibt's auch noch ein paar andere Einstellungen bei DRBD: no-disk-barrier; no-disk-flush. Falls Du batteriegepufferte RAID-Controller hast, werden die Daten damit als geschrieben betrachtet, wenn Sie im Cache des Controllers liegen. Falls keine Cache-Protection da ist, gibt es bei Störungen dann Datenverlust. Auch hier: Kann man mal ausprobieren, ob das was hilft bzw. wieviel das ausmacht.

[bluestar]

Das ist bei gemieteten Root-Servern (Hetzner) glaub ich nicht so einfach (zumindest hab ich das noch nie gemacht). Aber ich mach mich mal schlau was das kosten würde, aber erstmal checke ich die Möglichkeiten die ich noch habe mit optimieren.

Verwendest du eine dedizierte GBit Verbindung zwischen beiden Servern??

[Exxter]

Das ist bei gemieteten Root-Servern (Hetzner) glaub ich nicht so einfach (zumindest hab ich das noch nie gemacht). Aber ich mach mich mal schlau was das kosten würde, aber erstmal checke ich die Möglichkeiten die ich noch habe mit optimieren.

Verwendest du eine dedizierte GBit Verbindung zwischen beiden Servern??

Nein, die Server stehen nur beide am gleichen Standort (Falkenstein) aber in unterschiedlichen RZ's. Hmmm, aber stimmt, ich habe mich auf auf die ausgehandelte Geschwindigkeit auf beiden Servern verlassen:

Code: Alles auswählen

root@server ~ # ethtool eth0|grep Speed
        Speed: 1000Mb/s
root@server ~ #

Den echten Durchsatz habe ich nie gemessen. Gleich mal iperf installieren.

[bluestar]

Nein, die Server stehen nur beide am gleichen Standort (Falkenstein) aber in unterschiedlichen RZ's. Hmmm, aber stimmt, ich habe mich auf auf die ausgehandelte Geschwindigkeit auf beiden Servern verlassen:

Hast du dir über die Sicherheit dabei Gedanken gemacht? Du machst DRBD Datenblöcke hoffenltich über einen verschlüsselten Tunnel zwischen beiden Servern.

Den echten Durchsatz habe ich nie gemessen. Gleich mal iperf installieren.

Aktuell hat du auf jeden Fall schon mal ein Bottleneck, je stärker die Dienste auf deinem Server frequentiert werden, je mehr DRBD Daten musst du über das gleiche Netzwerkdevice zu dem zweiten Server senden.

[Exxter]

Hast du dir über die Sicherheit dabei Gedanken gemacht? Du machst DRBD Datenblöcke hoffenltich über einen verschlüsselten Tunnel zwischen beiden Servern.

Aktuell hat du auf jeden Fall schon mal ein Bottleneck, je stärker die Dienste auf deinem Server frequentiert werden, je mehr DRBD Daten musst du über das gleiche Netzwerkdevice zu dem zweiten Server senden.

Ja, die Verbindung läuft über OpenVPN. Zum Durchsatz (Messung während des normalen Betriebs):

Code: Alles auswählen

root@server2 ~ # iperf -c 10.8.0.1
------------------------------------------------------------
Client connecting to 10.8.0.1, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 10.8.0.6 port 42712 connected with 10.8.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   876 MBytes   735 Mbits/sec
root@server2 ~ #

Code: Alles auswählen

root@server2 ~ # iperf -c 10.8.0.1 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 10.8.0.1, TCP port 5001
TCP window size:  108 KByte (default)
------------------------------------------------------------
[  5] local 10.8.0.6 port 42714 connected with 10.8.0.1 port 5001
[  4] local 10.8.0.6 port 5001 connected with 10.8.0.1 port 40356
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   499 MBytes   419 Mbits/sec
[  4]  0.0-10.0 sec   460 MBytes   385 Mbits/sec
root@server2 ~ #

Sollte passen..

[Milbret]

Was mich noch wundert ist, dass er schon 61 MBs geswappt hat.
Vielleicht solltest du auch mal in der sysctl.conf vm.swappiness runter setzen.
Ggf. sogar auf einen sehr niedrigen Wert oder gar 0.
Wobei 10 bei einem Server noch okay sein dürfte.
Default war glaube 60 was für Desktop okay aber bei Server eher suboptimal ist.
Da du nur 4 von 16 GB nutzt, wäre swappen also nur unnötige Plattenlast.
Gerade bei einem DB Server sollte swappen vermieden werden.

Ansonsten wäre eine Screenshot von atop mit möglichst allen Daten hilfreich.
Schau dort auch mal wie die Platten ausgenutzt werden.
Also nicht Durchsatz von IO Last in %
Wenn diese trotz minimaler Lese/Schreiblast fast durchgängig auf 100% und busy steht, scheint die Platte ordentilich zu tun zu haben.
Dann wäre wirklich eine hoher IO Wait durch langsame DB Abfragen eine Ursache.
Dazu müsstest du aber mal per Profiler schauen welche Abfragen im Schnitt laufen und welche z.B. lange dauern.
Ggf. kannst du MariaDB auch sagen, dass langsame Abfragen geloggt werden sollen.
Kenne diese Möglichkeit von PostgreSQL, müsstest also schauen was MariaDB für Möglichkeiten bietet.

Auch müsstest du mal schauen wie die Last ist, wenn eine Abfrage gegen die Java Oberfläche läuft.
Auch solltest du die Logs deines Java Application Server prüfen.
Bei Tomcat z.B. /var/log/tomcat/catalina.out
Dort könnten ggf. auch Fehlermeldungen stehen falls es welche gibt, die aber nur weggeloggt werden aber keinen Abbruch der Anfrage verursachen.
Träge Seitenaufrufe könnten aber auch wieder Hinweis auf langsame Datenbankabfragen sein, da dann der Application Server auf eine DB Abfrage warten muss.
Die Synthome würden passen.

I.d.R. sollte man auch den DB Server und die Webserver physisch trennen um gerade Lastprobleme zu vermieden.
Aber das ist dann eine andere Baustelle

Martin