EXT4 und jbd2 Performance Probleme?

[WHF]

Hallo Leute!

Ich bin gerade dabei die ganzen VServer von Linux VServer, was ich jahrelang problemlos verwendet habe, zu Proxmox zu migrieren. Soweit alles kein Problem, ich hab das alles lange getestet und finde PM an sich echt gut.

Jetzt zum Problem:
Als ich den ersten Server fertig hatte, ist mir schon die schlechtere Performance aufgefallen. Insbesondere das EXT4 Filesystem macht negativ auf sich aufmerksam bzw. ist der Grund, genauer gesagt der IO Delay. Es ist deutlich höher als vorher geworden. Umgezogen wurden 2 kleinere Gastsysteme auf identische Hardware, einem Xeon E3-1275 V5 mit zwei NVMe SSD Laufwerken in SW-Raid1 Setup und 64 GB RAM. Ich hab den Server schon bei 16% wa gesehen... das war vorher undenkbar.

Als ich vor kurzem einen zweiten Server umgezogen habe, das selbe. Nur dieses mal richtig krass, weil dieser Server ein bisschen mehr zu tun hat und mit normalen Platten arbeitet (wie vorher auch). Zu Stosszeiten bleibt das Ding jetzt fast stehen mit über 50% wa. Auslöser sind die jbd2 Prozesse.

Kennt das Problem jemand und weiss eine Lösung. Oder ist es möglich, für die LXC Container (jeweils eigene LV's) auch ein anderes FS als EXT4 zu verwenden, z. B. XFS?

Thx!

Gruß Holger

 

[bluesite]

was sagt denn pveperf

CPU BOGOMIPS: 39912.72
REGEX/SECOND: 1914301
HD SIZE: 3.32 GB (/dev/sda1)
BUFFERED READS: 489.98 MB/sec
AVERAGE SEEK TIME: 0.13 ms
FSYNCS/SECOND: 5717.93
DNS EXT: 33.73 ms
DNS INT: 22.04 ms

ich hatte auch Performance Probleme habe auch ext4 anstatt zfs
habe 5.1 unter Debian am Laufen
ich habe meine ext4 Partitionen mit diesen Optionen eingebunden:
ext4 auto,noatime,barrier=0 0 1
mit aktivierem barrier war es sehr viel langsamer
ich habe allerdings eine usv am Server gegen Stromausfälle und Störungen

 

[WHF]

Ohne Last sieht das bei mir so aus:

CPU BOGOMIPS: 54528.00
REGEX/SECOND: 3811171
HD SIZE: 49.09 GB (/dev/mapper/vg0-root)
BUFFERED READS: 207.60 MB/sec
AVERAGE SEEK TIME: 6.23 ms
FSYNCS/SECOND: 49.55
DNS EXT: 19.73 ms
DNS INT: 8.84 ms (your-server.de)

Ich hab jetzt die Platten und den Ram prüfen lassen und dabei konnte kein defekt festgestellt werden. Was nach dem Update und reboot aufgefallen ist; Die Anzeige von iotop hat sich verändert und der Server läuft nun annehmbar.

Vorher war die Anzeige so:

14666 be/3 root 0.00 B/s 7.61 K/s 0.00 % 68.61 % [jbd2/dm-3-8]
12026 be/3 root 0.00 B/s 0.00 B/s 0.00 % 23.42 % [jbd2/dm-2-8]
12117 be/4 systemd- 0.00 B/s 106.61 K/s 0.00 % 0.59 % mysqld --basedir=/usr --datadir=/var/lib~t=/var/run/mysqld/mysqld.sock --port=3306
11430 be/4 systemd- 0.00 B/s 0.00 B/s 0.00 % 0.35 % mysqld --basedir=/usr --datadir=/var/lib~t=/var/run/mysqld/mysqld.sock --port=3306
....


jetzt sieht es so aus:
34 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/4]
28 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/3]
16 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/1]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/0]
52 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/7]
46 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/6]
22 be/4 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [ksoftirqd/2]
601 be/3 root 0.00 B/s 18.63 K/s 0.00 % 0.00 % [jbd2/dm-0-8]

Also vollkommener Müll. 99% hat vorher keiner diese Prozesse angezeigt und der jbd2 Prozess hat jetzt immer 0%. Das kann nicht sein und ist auf keinem anderen Server so. Das soll angeblich ein Bug in iotop sein, soweit ich gelesen hab. Nur wieso kommt das erst, nachdem der Kernel aktualisiert wurde???

jetzt proxmox-ve: 5.1-25 (running kernel: 4.13.4-1-pve
vorher proxmox-ve: 5.0-20 (running kernel: 4.10.17-2-pve)

Ich bleib auf jedem Fall dran. Jetzt kommen erst mal noch zwei SSD rein, damit man wieder mal ruhig schlafen kann.

Gruß Holger

 

[bluesite]

ist aber immer noch hoch,

bei mir sieht es so aus

Virtual Environment 5.1-36
Linux esxi 4.13.4-1-pve #1 SMP PVE 4.13.4-26 (Mon, 6 Nov 2017 11:23:55 +0100) x86_64 GNU/Linux

hab 3 SSDs drin und paar normale Platten für Daten die per nfs in die VMs gemountet sind
auf einer 512 GB SSD hab ich die VMs und auf auf die 2. 512 GB SSD kommen die Backups die dann noch mal auf ne ext. HDD gesichert werden

268 ? S 0:03 [jbd2/sda1-8]
620 ? S 0:00 [jbd2/sda5-8]
625 ? S 0:00 [jbd2/sdf1-8]
628 ? S 0:05 [jbd2/sda7-8]
629 ? S 0:00 [jbd2/sda6-8]
2017 ? S 0:00 [jbd2/dm-0-8]
2020 ? S 0:01 [jbd2/dm-1-8]
2023 ? S 0:02 [jbd2/dm-2-8]
2026 ? S 0:04 [jbd2/dm-3-8]
2029 ? S 0:00 [jbd2/dm-4-8]

 

[Deleted member 34654]

Hetzner, bestimmt Hardware Fehler.

Ext3 hat mehr Speed als ext4 und läuft meiner Meinung stabilere.

 

[janosch1337]

Hallo Zusammen,

ich hab da das selbe problem...

Linux Debian-95-stretch-64-minimal 4.15.18-9-pve #1 SMP PVE 4.15.18-30 (Thu, 15 Nov 2018 13:32:46 +0100) x86_64 GNU/Linux

CPU BOGOMIPS: 54400.56
REGEX/SECOND: 3431460
HD SIZE: 1816.41 GB (/dev/mapper/root)
BUFFERED READS: 45.24 MB/sec
AVERAGE SEEK TIME: 14.84 ms
FSYNCS/SECOND: 1121.29
DNS EXT: 31.75 ms

der FSYNCS/SECOND war sonst auf 50... habe jetzt "auto,noatime,barrier=0" drin. dadurch ist es ein bisschen besser geworden. aber IO delay ist recht hoch bei kleiner auslastung und die speeds der disks sind auch nicht besonders hoch..

aber das sind noch keine disk werte die ich von 2x 2TB im raid 1 (ext4) erwarte. oder ist das grundsätzlich die falsche dateisystem cfg für proxmox?

 

[zash1958]

Das sind Onboard NVMe-SSD Laufwerke?

Nicht dass die irgendwo auf demselben PCI Lane oder SATA-Bus hängen und so sich selber die Bandbreite völlig kaputt machen? Oder Board/Bios haben einen Designfehler?

Besteht die Möglichkeit, einen Test mit 2 Testfestplatten an einem normalen SATA Anschluss zu machen?

 

[janosch1337]

nein es sind 2 einzelne hdds 2x 2TB SATA im SW RAID 1 verbund. ich habe mitlerweile schon viel ausprobiert. problem ist wenn die festplatten ext4 formatiert sind und ich auf dem host eine 30gb datei mit dd schreibe geht die load auf über 20 und das IO delay ist über 50%. Der Rechner ist dann kaum noch bedienbar.

 

[zash1958]

Write-cache auf den Platten selber ist eingeschaltet?

Da ist unser hauseigenes HW-Raid1 auf Standard WD RE4 ja deutlich schneller

Ist schon sehr seltsam: SSD Platten per SW-RAID sollten normalerweise schon d e u t l i c h flotter arbeiten. Das Alignement auf den SSD ist aber korrekt? Ich hatte mal einen ähnlichen Fall mit traumatös mieser Schreibdatenrate auf einem SSD-RAID1. Da haben die Partition-Alignements nicht gestimmt. Lesen war OK, Schreiben dramatisch schlecht