Bottleneck 10 GBit | Debian 10 | Datenrate ~ 166 MB/s

[slu]

Hallo,

wir haben zwei Debian 10 Server welche über einen 10 GBit Switch verbunden sind, allerdings erreiche
ich nicht die Datenraten welche ich mir erhofft habe ( ~ 400 MB/s).

Vielleicht hat jemand eine Idee wie man das Problem weiter eingrenzen kann, folgende Tests habe ich bisher durchgeführt:

Server KVM:
Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz

Code: Alles auswählen

root@kvm:/mnt/vmstorage# dd if=/dev/zero of=file.test bs=4M count=10000
41943040000 bytes (42 GB, 39 GiB) copied, 40,8442 s, 1,0 GB/s

Server Backup:
Intel(R) Xeon(R) E-2246G CPU @ 3.60GHz

Code: Alles auswählen

root@backup:/mnt/disk1# dd if=/dev/zero of=file.test bs=4M count=10000
41943040000 bytes (42 GB, 39 GiB) copied, 93,4865 s, 449 MB/s

Ein Netzwerktest mit iperf:

Code: Alles auswählen

root@backup:/mnt/disk1# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 10.0.0.49 port 5001 connected with 10.0.0.44 port 40442
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  11.0 GBytes  9.41 Gbits/sec
[  4] local 10.0.0.49 port 5001 connected with 10.0.0.44 port 40444
[  4]  0.0-10.0 sec  10.9 GBytes  9.35 Gbits/sec

Kopieren mit scp:

Code: Alles auswählen

root@kvm:/mnt/vmstorage# scp file.test backup:/mnt/disk1/fiel.test_kvm_1
file.test               100%   39GB 152.9MB/s   04:21

Kopieren mit rsync:

Code: Alles auswählen

root@kvm:/mnt/vmstorage# rsync -avh file.test backup:/mnt/disk1/fiel.test_kvm_2
sending incremental file list
file.test

sent 41.95G bytes  received 35 bytes  166.15M bytes/sec
total size is 41.94G  speedup is 1.00

Hier ist natürlich in beiden Fällen SSH mit im Spiel, das Limit könnte also die CPU sein?
Oder liegt es am fehlenden Jumbo Frame / MTU?

Primär möchte ich große qcow2 Dateien so schnell als möglich übertragen, also eine große Datei.

[unitra]

An der MTU size liegt das ganz bestimmt nicht.

Da KVM im Spiel ist könnte es der Flaschenhals sein, also ohne KVM testen, ohne openvSwitch, ohne Softwarevirtualisierung.

Für einen Perfomrancetest punkt-zu-punkt Verbindung (ohne Switch), Server direkt miteindaner verbinden und dann erneut testen, ohne Softwarevirtualisierung.

Es könnte die NIC Hardware sein (Chip/Design) nicht alle NIC's bieten "wire-speed" also 1,25 GByte/s oder 10Gbit/s.

Möglicherweise ist es auch der eingesetzte NIC Treiber.

Das wären die üblichen

[slu]

Da KVM im Spiel ist könnte es der Flaschenhals sein, also ohne KVM testen, ohne openvSwitch, ohne Softwarevirtualisierung.

Es handelt sich um den KVM Host, also keine VM.

Für einen Perfomrancetest punkt-zu-punkt Verbindung (ohne Switch), Server direkt miteindaner verbinden und dann erneut testen, ohne Softwarevirtualisierung.

Die Server sind direkt mit einem Netgear [1] XS716T verbunden, eine direkte Verbindung hatte ich in der Tat noch nicht ausprobiert.
Aber müsste das dann nicht auch mit iperf auffallen?

Es könnte die NIC Hardware sein (Chip/Design) nicht alle NIC's bieten "wire-speed" also 1,25 GByte/s oder 10Gbit/s.

Oh ich hatte die extra raus kopiert und nicht gepostet:
KVM Intel 10-Gigabit X540-AT2
Backup Intel 10G X550T

[1] https://www.netgear.de/business/product ... fikationen

[Livingston]

Das Ergebnis von iperf ist ja eindeutig: Die beteiligten Netzkomponenten bringen die Leistung.

Viel mehr sagen da

Code: Alles auswählen

root@kvm:/mnt/vmstorage# dd if=/dev/zero of=file.test bs=4M count=10000
41943040000 bytes (42 GB, 39 GiB) copied, 40,8442 s, 1,0 GB/s

und

Code: Alles auswählen

root@backup:/mnt/disk1# dd if=/dev/zero of=file.test bs=4M count=10000
41943040000 bytes (42 GB, 39 GiB) copied, 93,4865 s, 449 MB/s

aus.
Hier würde ich erst mal mit verschiedenen Werten für bs testen, was bei der Speicherung auf Platten/SSDs (?) noch herauszuholen ist. HDD/SSD-Performance ist natürlich ein Thema für sich. Zu beachten ist dann auch, wie diese angebunden sind: SATA, NVMe, ...

[slu]

Der KVM-Server fährt ein Raid 6 (Adaptec ASR8805) über 8x SSDs und bringt ja 1 GB/s (zumindest in dem Schreibtest mit /dev/zero).
Das Backup hat ein Raid 10 (Adaptec ASR8405) über 4x SATA6 Festplatten, das hier nur 449 MB/s herauskommen ist also kein Wunder.

Aber, müsste ich dann beim kopieren über das Netzwerk nicht auch in diese Richtung (~ 400 MB/s) kommen, abzüglich dem Overhead für das SSH?
Irgendwas bremst, ich hab im Moment nur keine Idee wie ich das weiter eingrenzen/austesten kann.

[Livingston]

Dieser SSH-Overhead kann je nach kryptographischer Hardware-Unterstützung ziemlich dick sein. Um mehr herauszukriegen, kannst Du ja mal ein scp von einer lokalen Maschine zu sich selbst ausmessen z.B. mit:

Code: Alles auswählen

$ scp ~/dicke1GBDatei localhost:/dicke1GBkopie

[bluestar]

Mach doch mal den Übertragungstest mit netcat.

[MSfree]

Dieser SSH-Overhead kann je nach kryptographischer Hardware-Unterstützung ziemlich dick sein.

An der Befehlssatzerweiterung AES-NI mangelt es dem Xeon E5-2640 v4 auf jeden Fall nicht.

[slu]

Code: Alles auswählen

$ scp ~/dicke1GBDatei localhost:/dicke1GBkopie

Gute Idee, hier das Ergebnis:

Code: Alles auswählen

root@backup:/mnt/disk1# scp file.test backup:/mnt/disk1/file.test_localhost
file.test                                                                        100%   39GB 180.7MB/s   03:41

Code: Alles auswählen

top - 10:15:57 up 15:25,  3 users,  load average: 3,64, 3,17, 1,59
Tasks: 196 total,   1 running, 195 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,5 us,  0,5 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :  32010,5 total,    282,6 free,    312,9 used,  31415,0 buff/cache
MiB Swap:  32611,0 total,  32603,5 free,      7,5 used.  31234,1 avail Mem

Ein Punkt ist mir noch aufgefallen (den ich evtl. unterschätzt habe?) das Ziel /mnt/disk1 ist ein LUKS Device.

Wenn das aber das Problem wäre, warum fällt das bei dd nicht auf?
Ist doch die Kombination SSH und LUKS Device ein Problem für die CPU? Der Load ist auch recht hoch beim lokalen scp.

[slu]

Mach doch mal den Übertragungstest mit netcat.

Code: Alles auswählen

root@kvm:~# dd if=/dev/zero bs=4M count=512 | nc -v backup 2222
Connection to backup 2222 port [tcp/*] succeeded!
512+0 Datensätze ein
512+0 Datensätze aus
2147483648 bytes (2,1 GB, 2,0 GiB) copied, 1,8528 s, 1,2 GB/s

Am Netzwerk liegt es nicht würde ich sagen.

[bluestar]

Mach doch mal den Übertragungstest mit netcat.

Code: Alles auswählen

root@kvm:~# dd if=/dev/zero bs=4M count=512 | nc -v backup 2222
2147483648 bytes (2,1 GB, 2,0 GiB) copied, 1,8528 s, 1,2 GB/s

Dann mach das doch noch mal mit

Code: Alles auswählen

cat /mnt/vmstorage/file.test | nc -v backup 2222

Und schau mal schreib auf backup die netcat Ausgabe nach /dev/null => Dann weist du ob's am Lesen hängt

Dnach noch einmal und die schreibst die netcat Ausgabe auf backup in eine Datei => Dann weist du ob's die Schreibleistung von Backup ist.

[slu]

Wenn ich nc auf dem Backup nach /dev/null schicke gehen 1 GB/s durchs Netzwerk (dstat).
Zeigt nc auf eine Datei in /mnt/disk1 sehe ich eine Schreibleistung von ~ 400 MB/s, es liegt also nicht am LUKS Device.

Der KVM kann auch als Falschenhals ausgeschlossen werden, das Problem liegt am Backup.

[slu]

Das Rätsel ist gelöst, MSfree hat mich mit dem AES-NI auf eine Idee gebracht.

Es liegt am default Cipher, dieser ist bei Debian 10 chacha20-poly1305@openssh.com.
Sobald ich auf dem SSH Server den Cipher auf "Ciphers aes256-gcm@openssh.com" setze ist die volle Bandbreite vorhanden, bzw.
sieht man das erwartete Limit auf dem Backup Server:

chacha20-poly1305@openssh.com

Code: Alles auswählen

root@kvm:/mnt/vmstorage# scp file.test backup:/mnt/disk1/test
file.test                          100%   39GB 157.0MB/s   04:14

aes256-gcm@openssh.com

Code: Alles auswählen

root@kvm:/mnt/vmstorage# scp file.test backup:/mnt/disk1/test
file.test                          100%   39GB 384.4MB/s   01:44

Der default Chiper hat somit nichts vom dem AES-NI, mein SSH sollte aber auch mit einem AES256-GCM sicher sein oder
sehe ich das falsch?

Edit: Das ist wohl nicht so einfach mit dem chacha20-poly1305 vs. aes256-gcm zu beantworten, soweit ich das verstehe ist chacha20-poly1305 deutlich sicherer.

[slu]

Möchte man nur für den einen Kopiervorgang den Cipher wechseln kann man die Optione einfach mitgeben:

Code: Alles auswählen

scp -o Ciphers=aes256-gcm@openssh.com

[habakug]

Hallo,

wir hatten das schonmal vor einiger Zeit [1]. Bitte nach unten weiter lesen...
Ich verwende "blowfish-cbc" mit gutem Erfolg [2].
Habe gerade Urlaub, aber wir können mal paar Messungen über 1GB und/oder 10GB machen. Mit ähnlichem Equipment, habe ich nicht alles im Kopf.

Gruss, habakug

[1] viewtopic.php?f=30&t=152529&start=15#p1015225
[2] https://www.systutorials.com/improving- ... g-ciphers/

[slu]

Ich verwende "blowfish-cbc" mit gutem Erfolg [2].

Den blowfish habe ich schon seit einer Weile nicht mehr verwendet, OpenVPN hat irgendwan gewarnt das dieser unsicher wär.

Habe gerade Urlaub, aber wir können mal paar Messungen über 1GB und/oder 10GB machen. Mit ähnlichem Equipment, habe ich nicht alles im Kopf.

Würde mich sehr interessieren, bis dahin einen schönen Urlaub.

[wanne]

Edit: Das ist wohl nicht so einfach mit dem chacha20-poly1305 vs. aes256-gcm zu beantworten, soweit ich das verstehe ist chacha20-poly1305 deutlich sicherer.

Nein. Ganz im Gegenteil nimmt man chacha20-poly1305 eher auf schwacher Hardware. (Achtung: Maximale Performance und auf möglichst kleine Hardwarevoraussetzungen sind 2 unterschiedliche Ziele.) Für beide sind nicht ansatzweise Schwachstellen bekannt und AES ist weit besser untersucht. Wer die Hardware hat fährt mit AES eher besser.
3 Gigabit/s über SSH ist ziemlich sportlich viel mehr würde ich für unmöglich halten, da SSH immernoch singlethreadded verschlüsselt und vor allem plain TCP macht. Da ist bei ~10G auch üblicherweise Schluss. Auch sonst wird von OpenSSH explizit nicht auf IO-Performance wert gelegt.
Wenn du mehr willst musst du in Richtung verteilte Dateisysteme gehen. Netperf zeigt ja, dass das Netzwerk bringt, was es soll.