NIC Bonding - Performanceprobleme

DerTom246 · Feb 20, 2021

Hallo zusammen,

ich bitte um Infos, ob jemand einen Linux-Bond betreibt und dabei die gleichen Probleme hat, die mich hier plagen.

Um den Durchsatz für die VM bzw. die angeschlossenen Clients zu gewährleisten, habe ich aus zwei 10G-SFP+ (Mellanox-Karte) einen Linux-Bond erstellt:

Code:

iface ens6f0 inet manual
iface ens6f1 inet manual

auto bond1
iface bond1 inet manual
        bond-slaves ens6f0 ens6f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-use-carrier 1
        bond-lacp-rate 1
        bond-min-links 1
        bond-xmit-hash-policy layer3+4
    mtu 9000
    
auto vmbr1
iface vmbr1 inet manual
        bridge-ports bond1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4000
    mtu 9000

Dieses Netzwerk habe ich nun diversen VM zugewiesen und dort eingebunden. Die Clients erreichen die VM's und die VM's haben eine Netzwerk-/Internetverbindung.

Das Problem besteht nun darin, dass ich von einem 10G-Netz weit weg bin. Ich liege immer um die 60-70 MB/s!?

Wo muss ich ansetzen bzw. was ist falsch konfiguriert?

Viele Grüße

Dunuin · Feb 20, 2021

Hängt der Server an einem Switch?
Falls ja, hast du da auch Jumboframes aktiviert?
Der Trunk ist am Switch auch passend für LACP eingestellt?
Die VMs nutzen virtio NICs (die schaffen bei mir nie mehr als 5Gbit)?

Ich habe hier ein active-passive (failover) bond aus 10G Connectx3 + 1G Intel NIC. Also ohne lastausgleich über LACP bei mir und da gehen so 9,7 Gbit TCP traffic durch und 2 Gbit UDP traffic. Wenn virtio im Spiel ist halt nicht mehr als 5 Gbit TCP traffic.

Wie sieht bei dir das Routing aus? Sind die 60-70 MB/s im selben VLAN oder bremst da vielleicht einfach der Router?

Die Gegenseite ist schnell genug? Wenn ich 1500 statt 9000 MTU nutze, dann bremst z.B. mein FreeNAS Server meinen Proxmox Server aus und es gegen nur noch 7 Gbit TCP durch die Leitung. Haben zwar beide die selben NICs verbaut, aber auf dem Proxmox Server geht die CPU-Last nur minimal hoch und auf dem FreeNAS Server springt die CPU-Last von einem Kern von 0 auf 100% hoch und dann ist wohl einfach die CPU der Flaschenhals.

Hast du mal mit iperf3 die Performance gemessen, um da langsames SMB/NFS durch langsame Schreibvorgänge auszuschließen?

bobmc · Feb 20, 2021

I don't use bonding but I get 9.7Gb / s between VM and client. Strangely, at the same time host to client is only 6Gb / s - and I have no idea why - but seeing as the main limit on I / O is the storage pool, I don't mind living with it for now.

DerTom246 · Feb 20, 2021

Dunuin said:
Hängt der Server an einem Switch?
Falls ja, hast du da auch Jumboframes aktiviert?
Der Trunk ist am Switch auch passend für LACP eingestellt?
Die VMs nutzen virtio NICs (die schaffen bei mir nie mehr als 5Gbit)?

Ich habe hier ein active-passive (failover) bond aus 10G Connectx3 + 1G Intel NIC. Also ohne lastausgleich über LACP bei mir und da gehen so 9,7 Gbit TCP traffic durch und 2 Gbit UDP traffic. Wenn virtio im Spiel ist halt nicht mehr als 5 Gbit TCP traffic.

Wie sieht bei dir das Routing aus? Sind die 60-70 MB/s im selben VLAN oder bremst da vielleicht einfach der Router?

Die Gegenseite ist schnell genug? Wenn ich 1500 statt 9000 MTU nutze, dann bremst z.B. mein FreeNAS Server meinen Proxmox Server aus und es gegen nur noch 7 Gbit TCP durch die Leitung. Haben zwar beide die selben NICs verbaut, aber auf dem Proxmox Server geht die CPU-Last nur minimal hoch und auf dem FreeNAS Server springt die CPU-Last von einem Kern von 0 auf 100% hoch und dann ist wohl einfach die CPU der Flaschenhals.

Hast du mal mit iperf3 die Performance gemessen, um da langsames SMB/NFS durch langsame Schreibvorgänge auszuschließen?

Hallo Dunuin,

ja, der Server hängt an einem Switch. Auf allen Switches habe ich Jumboframes aktiviert und bei den VM in der Konfiguration 'MTU=9000' angegeben. Die 60-70MB/s habe ich sowohl im selben Vlan als auch in unterschiedlichen. Der 'Router' ist OPNsense - auch mit 10G angebunden - und die CPU langweilt sich und hat kaum etwas zu tun.

Komisch ist auch, was mir auch noch auffällt, dass ich teilweise einen Client/VM nicht erreichen kann, falls ein anderer Client/VM gerade darauf zugreift oder diese selbst Netzwerktraffic erzeugt bzw. TV-Server nimmt Sendung auf und die Datei wird auf einem SMB-Share gespeichert. Dann ist der TV-Server nicht zu erreichen... Dann werde ich mich mal mit iperf3 beschäftigen...

Die netplan-config (TV-Server) sieht übrigens so aus:

Code:

network:
renderer: NetworkManager    ##changes default from networkd to NetworkManager for Cockpit
ethernets:
    ens18:
      dhcp4: true
      mtu: 9000
version: 2

und

Code:

ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 8e:c1:d1:9e:6d:b6 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast 
    333022977  4604162  0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    62190476919 7749060  0       0       0       0     
    altname enp0s18

Sieht für mich gut aus...

Muss ich noch etwas beachten, wenn mehrere VMs auf den gleichen Bond zugreifen und sich auch darüber untereinander erreichen sollen?

bobmc said:
I don't use bonding but I get 9.7Gb / s between VM and client. Strangely, at the same time host to client is only 6Gb / s - and I have no idea why - but seeing as the main limit on I / O is the storage pool, I don't mind living with it for now.

Hi bobmc,

I like to try things... I wanted to know if bonding two 10G-NICs can be done and if there is any benefit by doing it. Right now I would say no - but I would also like to have the 'backup'-security of two connections.

noPa$$word · Feb 21, 2021

Bei mir war es ein Treiber Problem.

Ich hatte auch eine Karte mit Mellanox Chipsatz. Dafür gibt es auf der Mellanox-Seite momentan nur Treiber bis Debian 10.5 (Proxmox 6.3 ist Debian 10.6, denke ich), der sich in Proxmox auch nicht installieren lässt. Ich hab's gelassen und habe mir eine Karte mit Intel Chipsatz besorgt. Jetzt funktioniert es.

DerTom246 · Feb 21, 2021

So, habe mal mit iperf3 den Durchsatz gemessen:

Win10 / smb-shares NAS:

Code:

[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   470 MBytes  3.94 Gbits/sec
[  4]   1.00-2.00   sec   471 MBytes  3.95 Gbits/sec
[  4]   2.00-3.00   sec   472 MBytes  3.96 Gbits/sec
[  4]   3.00-4.00   sec   466 MBytes  3.91 Gbits/sec
[  4]   4.00-5.00   sec   472 MBytes  3.96 Gbits/sec
[  4]   5.00-6.00   sec   474 MBytes  3.98 Gbits/sec
[  4]   6.00-7.00   sec   477 MBytes  4.00 Gbits/sec
[  4]   7.00-8.00   sec   476 MBytes  3.99 Gbits/sec
[  4]   8.00-9.00   sec   477 MBytes  4.00 Gbits/sec
[  4]   9.00-10.00  sec   478 MBytes  4.01 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  4.62 GBytes  3.97 Gbits/sec                  sender
[  4]   0.00-10.00  sec  4.62 GBytes  3.97 Gbits/sec                  receiver

Win10 / TV-Server

Code:

[  4] local 10.246.13.10 port 7420 connected to 10.246.37.222 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   477 MBytes  4.00 Gbits/sec
[  4]   1.00-2.00   sec   480 MBytes  4.03 Gbits/sec
[  4]   2.00-3.00   sec   480 MBytes  4.02 Gbits/sec
[  4]   3.00-4.00   sec   480 MBytes  4.03 Gbits/sec
[  4]   4.00-5.00   sec   480 MBytes  4.03 Gbits/sec
[  4]   5.00-6.00   sec   480 MBytes  4.03 Gbits/sec
[  4]   6.00-7.00   sec   481 MBytes  4.04 Gbits/sec
[  4]   7.00-8.00   sec   481 MBytes  4.04 Gbits/sec
[  4]   8.00-9.00   sec   481 MBytes  4.03 Gbits/sec
[  4]   9.00-10.00  sec   481 MBytes  4.04 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  4.69 GBytes  4.03 Gbits/sec                  sender
[  4]   0.00-10.00  sec  4.69 GBytes  4.03 Gbits/sec                  receiver

TV-Server / NAS (beide über 10G-Bond)

Code:

[  5] local 10.246.37.222 port 59970 connected to 10.246.37.221 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.86 GBytes  16.0 Gbits/sec    0   1.16 MBytes       
[  5]   1.00-2.00   sec  1.91 GBytes  16.4 Gbits/sec    0   1.42 MBytes       
[  5]   2.00-3.00   sec  1.90 GBytes  16.3 Gbits/sec    0   1.66 MBytes       
[  5]   3.00-4.00   sec  1.89 GBytes  16.2 Gbits/sec    0   1.66 MBytes       
[  5]   4.00-5.00   sec  1.96 GBytes  16.8 Gbits/sec    0   2.38 MBytes       
[  5]   5.00-6.00   sec  1.88 GBytes  16.2 Gbits/sec    0   2.38 MBytes       
[  5]   6.00-7.00   sec  1.89 GBytes  16.3 Gbits/sec    0   2.38 MBytes       
[  5]   7.00-8.00   sec  1.89 GBytes  16.2 Gbits/sec    0   2.38 MBytes       
[  5]   8.00-9.00   sec  1.88 GBytes  16.2 Gbits/sec    0   2.38 MBytes       
[  5]   9.00-10.00  sec  1.89 GBytes  16.2 Gbits/sec    0   2.38 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  19.0 GBytes  16.3 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  19.0 GBytes  16.3 Gbits/sec                  receiver

Habe dann Win10 / NAS mal 120 Sekunden laufen lassen:

Code:

[  4] 117.00-118.00 sec   495 MBytes  4.15 Gbits/sec
[  4] 118.00-119.00 sec   492 MBytes  4.13 Gbits/sec
[  4] 119.00-120.00 sec   489 MBytes  4.10 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-120.00 sec  56.7 GBytes  4.06 Gbits/sec                  sender
[  4]   0.00-120.00 sec  56.7 GBytes  4.06 Gbits/sec                  receiver

Das Netzwerk scheint zu funktionieren? Oder?
Die 4GB-Grenze bei Win10 ist leider M§-bedingt und lässt sich mit Win10 Pro wohl nicht aufheben.

Trotzdem verläuft das kopieren einer Datei von einer pcie4-ssd dann so:

Mit der SSD kriege ich die 10G nicht ausgelastet, 64 MB/s sind aber doch etwas wenig...

pakuzaz · Feb 21, 2021

Ggf der Controller oder die Festplatten?

DerTom246 · Feb 21, 2021

pakuzaz said:
Ggf der Controller oder die Festplatten?

Der zpool zeigt keine Probleme:

Code:

 state: ONLINE
  scan: scrub repaired 0B in 0 days 06:55:48 with 0 errors on Sun Feb 14 07:19:50 2021
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda1    ONLINE       0     0     0
            sdc1    ONLINE       0     0     0
            sdb1    ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            sdd1    ONLINE       0     0     0
            sde1    ONLINE       0     0     0
        cache
          sdd2      ONLINE       0     0     0
          sde2      ONLINE       0     0     0

errors: No known data errors

smartctl zeigt für alle Laufwerke keine Fehler an.

Ich habe ja die smb.conf im Auge. Mal schauen...

H4R0 · Feb 21, 2021

DerTom246 said:

Der zpool zeigt keine Probleme:

Code:

 state: ONLINE
  scan: scrub repaired 0B in 0 days 06:55:48 with 0 errors on Sun Feb 14 07:19:50 2021
config:

        NAME        STATE     READ WRITE CKSUM
        zroot       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda1    ONLINE       0     0     0
            sdc1    ONLINE       0     0     0
            sdb1    ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            sdd1    ONLINE       0     0     0
            sde1    ONLINE       0     0     0
        cache
          sdd2      ONLINE       0     0     0
          sde2      ONLINE       0     0     0

errors: No known data errors

smartctl zeigt für alle Laufwerke keine Fehler an.

Ich habe ja die smb.conf im Auge. Mal schauen...

ZFS falsch konfiguriert, cache und slog auf gleicher platte ist performance killer.

Der slog macht bei raidz1 auf ssd wenig sinn und cache braucht nicht redundant sein.

Teste mal die pool performance, hat nichts mit dem netzwerk zu tun.

Würde slog und cache raus nehmen und erneut testen.

Code:

apt install fio

cd <pool_mount>

fio --name=seqwrite --filename=seqwrite.fio --refill_buffers --rw=write --direct=1 --loops=3 --ioengine=libaio --bs=1m --size=10G --runtime=60 --group_reporting

Dunuin · Feb 21, 2021

Dein Transfer dort sieht für mich auch eher so aus, als wenn da erst ein Cache gefüllt wird (ob nun SLOG, ARC, Page File im RAM oder RAM Cache auf der SSD) und der dann voll ist und dann direkt auf die Laufwerke geschrieben wird, was halt lahm ist. Also ich würde da auch eher auf zu lahme Laufwerke tippen als Probleme mit dem Netzwerk.

Bei den Win10 VMs kann das mit den 4Gbit übrigens normal sein. Wenn du kein Multiqueue benutzt dann kann die virtuelle CPU nur einen Kern für NEtzwerksachen benutzen. Und wenn die NIC nicht per PCI passthrough in die VM durchgereicht ist, dann kann die NIC kein Hardware Offloading nutzen und deine virtuelle CPU muss alles mögliche was Pakete angeht berechnen. Und wenn du virtio NICs benutzt, dann gehen da eh nur wenige Gbit durch bevor die vituelle NIC an die Grenzen stößt.

DerTom246 · Feb 22, 2021

H4R0 said:
ZFS falsch konfiguriert, cache und slog auf gleicher platte ist performance killer.

Der slog macht bei raidz1 auf ssd wenig sinn und cache braucht nicht redundant sein.

Teste mal die pool performance, hat nichts mit dem netzwerk zu tun.

Würde slog und cache raus nehmen und erneut testen.

Code:

apt install fio cd <pool_mount> fio --name=seqwrite --filename=seqwrite.fio --refill_buffers --rw=write --direct=1 --loops=3 --ioengine=libaio --bs=1m --size=10G --runtime=60 --group_reporting

Hallo H4R0,

der zpool liegt nicht auf SSDs - wird aus 3 x WD Red 8TB gebildet. Auf SSD liegen bzw. lagen logs und cache, die ich aus dem zpool entfernt habe. An der Performance oder dem Problem hat sich aber wenig geändert. Die Übertragungsrate bricht unverändert stark ein, jetzt sogar auf ca. 50 MB/s.

Scheint an dem zpool zu liegen. Hier die Ergebnisse des Tests nach Entfernung von log und cache:

Code:

fio-3.16
Starting 1 process
seqwrite: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=55.9MiB/s][w=55 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=292317: Mon Feb 22 04:04:39 2021
  write: IOPS=117, BW=118MiB/s (123MB/s)(7059MiB/60010msec); 0 zone resets
    slat (usec): min=353, max=74771, avg=8304.40, stdev=7550.50
    clat (nsec): min=2392, max=83019, avg=3237.85, stdev=2238.14
     lat (usec): min=356, max=74779, avg=8308.53, stdev=7550.87
    clat percentiles (nsec):
     |  1.00th=[ 2608],  5.00th=[ 2704], 10.00th=[ 2768], 20.00th=[ 2832],
     | 30.00th=[ 2896], 40.00th=[ 2960], 50.00th=[ 3120], 60.00th=[ 3216],
     | 70.00th=[ 3248], 80.00th=[ 3312], 90.00th=[ 3376], 95.00th=[ 3472],
     | 99.00th=[ 6944], 99.50th=[14784], 99.90th=[25984], 99.95th=[63744],
     | 99.99th=[83456]
   bw (  KiB/s): min=55296, max=1399505, per=92.45%, avg=111360.29, stdev=200009.85, samples=120
   iops        : min=   54, max= 1366, avg=108.64, stdev=195.30, samples=120
  lat (usec)   : 4=98.31%, 10=0.76%, 20=0.81%, 50=0.03%, 100=0.08%
  cpu          : usr=2.17%, sys=5.96%, ctx=43934, majf=0, minf=11
  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 rwts: total=0,7059,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=118MiB/s (123MB/s), 118MiB/s-118MiB/s (123MB/s-123MB/s), io=7059MiB (7402MB), run=60010-60010msec

AAHHHHH.... Schmerzen....

Der zpool ist encrypted und ich habe den CPU-Typ nicht auf 'host' gesetzt. AES war zwar aktiviert, die CPU war jedoch falsch.
Mit CPU=host sieht es schon anders aus:

Code:

fio-3.16
Starting 1 process
seqwrite: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=198MiB/s][w=198 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=29174: Mon Feb 22 04:16:43 2021
  write: IOPS=251, BW=252MiB/s (264MB/s)(14.8GiB/60001msec); 0 zone resets
    slat (usec): min=276, max=15646, avg=3747.03, stdev=1778.81
    clat (nsec): min=1097, max=1410.4k, avg=3050.08, stdev=15905.46
     lat (usec): min=278, max=15654, avg=3750.96, stdev=1779.68
    clat percentiles (nsec):
     |  1.00th=[  1320],  5.00th=[  1480], 10.00th=[  1624], 20.00th=[  1816],
     | 30.00th=[  1928], 40.00th=[  2024], 50.00th=[  2128], 60.00th=[  2224],
     | 70.00th=[  2352], 80.00th=[  2960], 90.00th=[  4576], 95.00th=[  4896],
     | 99.00th=[ 13504], 99.50th=[ 14912], 99.90th=[138240], 99.95th=[177152],
     | 99.99th=[749568]
   bw (  KiB/s): min=143360, max=1611776, per=100.00%, avg=258418.16, stdev=233484.85, samples=119
   iops        : min=  140, max= 1574, avg=252.29, stdev=228.03, samples=119
  lat (usec)   : 2=37.88%, 4=46.18%, 10=14.43%, 20=1.23%, 50=0.13%
  lat (usec)   : 100=0.03%, 250=0.07%, 500=0.02%, 750=0.02%
  lat (msec)   : 2=0.01%
  cpu          : usr=5.69%, sys=12.57%, ctx=106374, majf=0, minf=14
  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 rwts: total=0,15119,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=252MiB/s (264MB/s), 252MiB/s-252MiB/s (264MB/s-264MB/s), io=14.8GiB (15.9GB), run=60001-60001msec

Habe - zum testen - log und cache wieder eingebunden:

Code:

state: ONLINE
  scan: scrub repaired 0B in 0 days 06:55:48 with 0 errors on Sun Feb 14 07:19:50 2021
config:

        NAME                                                 STATE     READ WRITE CKSUM
        zpool                                                ONLINE       0     0     0
          raidz1-0                                           ONLINE       0     0     0
            sda1                                             ONLINE       0     0     0
            sdc1                                             ONLINE       0     0     0
            sdb1                                             ONLINE       0     0     0
        logs
          mirror-1                                           ONLINE       0     0     0
            scsi-SATA_CT250MX500SSD1_2008E28E399E-part1      ONLINE       0     0     0
            scsi-SATA_Samsung_SSD_860_S3YJNX0KC21992E-part1  ONLINE       0     0     0
        cache
          scsi-SATA_CT250MX500SSD1_2008E28E399E-part2        ONLINE       0     0     0
          scsi-SATA_Samsung_SSD_860_S3YJNX0KC21992E-part2    ONLINE       0     0     0
          
          
fio-3.16
Starting 1 process
seqwrite: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=209MiB/s][w=209 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=81373: Mon Feb 22 04:45:44 2021
  write: IOPS=254, BW=255MiB/s (267MB/s)(14.9GiB/60002msec); 0 zone resets
    slat (usec): min=256, max=14821, avg=3705.81, stdev=1744.66
    clat (nsec): min=1142, max=970847, avg=2860.67, stdev=10054.10
     lat (usec): min=258, max=14829, avg=3709.52, stdev=1745.78
    clat percentiles (nsec):
     |  1.00th=[  1416],  5.00th=[  1560], 10.00th=[  1656], 20.00th=[  1800],
     | 30.00th=[  1912], 40.00th=[  2008], 50.00th=[  2096], 60.00th=[  2192],
     | 70.00th=[  2320], 80.00th=[  2800], 90.00th=[  4448], 95.00th=[  4960],
     | 99.00th=[ 13248], 99.50th=[ 14528], 99.90th=[103936], 99.95th=[164864],
     | 99.99th=[374784]
   bw (  KiB/s): min=153600, max=1603584, per=99.97%, avg=260670.83, stdev=229311.91, samples=120
   iops        : min=  150, max= 1566, avg=254.48, stdev=223.93, samples=120
  lat (usec)   : 2=39.60%, 4=46.15%, 10=12.80%, 20=1.19%, 50=0.13%
  lat (usec)   : 100=0.02%, 250=0.09%, 500=0.01%, 1000=0.01%
  cpu          : usr=5.91%, sys=12.46%, ctx=110145, majf=0, minf=12
  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 rwts: total=0,15279,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=255MiB/s (267MB/s), 255MiB/s-255MiB/s (267MB/s-267MB/s), io=14.9GiB (16.0GB), run=60002-60002msec

Setze ich nun aber die Option sync=always (da wohl nur dann die Schreibvorgänge über log laufen), dann bricht die Performance wieder deutlich ein. Brauche ich dann ein log??

Viele Grüße

DerTom246 · Feb 22, 2021

Dunuin said:
Dein Transfer dort sieht für mich auch eher so aus, als wenn da erst ein Cache gefüllt wird (ob nun SLOG, ARC, Page File im RAM oder RAM Cache auf der SSD) und der dann voll ist und dann direkt auf die Laufwerke geschrieben wird, was halt lahm ist. Also ich würde da auch eher auf zu lahme Laufwerke tippen als Probleme mit dem Netzwerk.

Bei den Win10 VMs kann das mit den 4Gbit übrigens normal sein. Wenn du kein Multiqueue benutzt dann kann die virtuelle CPU nur einen Kern für NEtzwerksachen benutzen. Und wenn die NIC nicht per PCI passthrough in die VM durchgereicht ist, dann kann die NIC kein Hardware Offloading nutzen und deine virtuelle CPU muss alles mögliche was Pakete angeht berechnen. Und wenn du virtio NICs benutzt, dann gehen da eh nur wenige Gbit durch bevor die vituelle NIC an die Grenzen stößt.

Hallo Dunuin,

der Controller mit den Platten des zpool wird an die VM/NAS durchgereicht.

Welche NICs sind denn - wenn nicht virito - hier zu nutzen?

Wenn ich Mr. Google richtig verstanden habe, dann sind die 4GB für ein Win10pro der Maximalwert. Um diese Begrenzung aufzuheben, müsste ich mir eine Workstation-Lizenz kaufen... will ich nicht. Denke eher daran, den ganzen Win10-Kram gegen LInux zu tauschen.

Viele Grüße!

Dunuin · Feb 22, 2021

DerTom246 said:
Welche NICs sind denn - wenn nicht virito - hier zu nutzen?

Wenn ich Mr. Google richtig verstanden habe, dann sind die 4GB für ein Win10pro der Maximalwert. Um diese Begrenzung aufzuheben, müsste ich mir eine Workstation-Lizenz kaufen... will ich nicht. Denke eher daran, den ganzen Win10-Kram gegen LInux zu tauschen.

Viele Grüße!

Virtio ist schon das schnellste, wenn du kein PCI Passthrough machst. Wenn die Hardware es zulässt könnte man aber virtio noch über multiqueue schneller machen, dass da mehr als 1 CPU-Kern benutzt werden kann.
Schneller wäre dann nur noch SR-IOV nutzen und jeder VM eine eigene virtuelle NIC per PCI Passthrough durchreichen. Oder halt wirklich eine physische NIC pro VM druchreichen, wenn da kein SR-IOV per Hardware unterstützt wird.

Setze ich nun aber die Option sync=always (da wohl nur dann die Schreibvorgänge über log laufen), dann bricht die Performance wieder deutlich ein. Brauche ich dann ein log??

Mit "sync=always" zwingst du ZFS alle schnellen Async Writes durch langsame Sync Writes zu ersetzen. Das mag für die Datenintegrität nützlich sein, aber nicht für die Performance. Wenn ohne "sync=always" bei dir fast keine Sync Writes ankommen und dann das SLOG nichts zu tun hat, dann ist dein SLOG einfach überflüssig.

DerTom246 · Feb 22, 2021

Dunuin said:
Virtio ist schon das schnellste, wenn du kein PCI Passthrough machst. Wenn die Hardware es zulässt könnte man aber virtio noch über multiqueue schneller machen, dass da mehr als 1 CPU-Kern benutzt werden kann.
Schneller wäre dann nur noch SR-IOV nutzen und jeder VM eine eigene virtuelle NIC per PCI Passthrough durchreichen. Oder halt wirklich eine physische NIC pro VM druchreichen, wenn da kein SR-IOV per Hardware unterstützt wird.

Mit "sync=always" zwingst du ZFS alle schnellen Async Writes durch langsame Sync Writes zu ersetzen. Das mag für die Datenintegrität nützlich sein, aber nicht für die Performance. Wenn ohne "sync=always" bei dir fast keine Sync Writes ankommen und dann das SLOG nichts zu tun hat, dann ist dein SLOG einfach überflüssig.

PCI Passthrough der NICs... Ich habe hier noch eine single-port Mellanox rumliegen... Mir gehen aber die x4-Steckplätze aus...

Die Geschichte mit dem SR-IOV schaue ich mir mal an. Klingt interessant!

Kennst Du eine gute Quelle, wo ich genaueres über multi-queue lesen (how-to?) Mr. Google ist da eher zurückhaltend, wenn es um 'Proxmox multi-queue' geht.

Da der SLOG auf insgesamt 2 SSDs (mirror) liegt, hatte ich nicht gedacht, dass der Performanceeinbruch so gewaltig ist. Auch jetzt mit der 'richtigen CPU' für die VM reduziert sich der Durchsatz auf unter 50% (ca. 110 MB/s).

Vielen Dank für Deine/Eure Hilfe. Alleine hätte mich das Jahre gekostet - auch an Nervenkraft...

Dunuin · Feb 22, 2021

DerTom246 said:
PCI Passthrough der NICs... Ich habe hier noch eine single-port Mellanox rumliegen... Mir gehen aber die x4-Steckplätze aus...

Das Problem kenne ich...ich wünschte auch ich hätte mir ATX und keine mATX Boards geholt.

DerTom246 said:
Die Geschichte mit dem SR-IOV schaue ich mir mal an. Klingt interessant!

Das mit dem SR-IOV ist garnicht so leicht. Meine ConnectX3 scheint das z.B. zu können und die 1-Port NIC kann dann bis zu 64 Virtuelle Funktionen bereitstellen. Man hat dann quasi bis zu 64 NICs die man per PCI passthrough an die VMs durchreichen kann. Ist dann quasi so als hätte ich eine 64 Port NIC die sich aber einen Anschluss teilen (was ja aber mit tagged vlan nicht so das Problem wäre).
Es ist aber bei Mellanox unglaublich kompliziert und umständlich das SR-IOV überhaupt aktiviert zu bekommen. Egal welche Firmware-Version ich nehme, ich kann das SR-IOV zwar beim Booten in der Firmware der NIC sehen und aktivieren, es lässt sich dann aber wegen Bugs nicht speichern. Will ich das aktivieren muss ich per Tool die Konfigs von der ConnectX3 dumpen, dann per hand die Konfig-Datei umschreiben und die geänderte Konfig-Datei dann zurück auf die NIC flashen. Offizielle Infos dazu sind auch ziemlich spärlich.
Und dann muss das BIOS, Chipsatz und CPU auch erst SR-IOV unterstützen. Einfach nur IOMMU reicht da nicht. Bei meinem einen Mainboard mit 2600er Xeon würde SR-IOV z.B. gehen, bei dem billigeren Mainboard mit 1600er Xeon geht es dann wieder nicht, weil das wohl ein Feature ist, was den Mehrprozessor-CPUs vorbehalten ist.
Wenn ich das richtig verstanden habe und man erst einmal SR-IOV komplett zum laufen bekommen hat, dann kann man das wohl ganz normal per PCI Passthrough durchreichen. Nur das man dann halt nicht nur 1 sondern bis zu 64 "NICs" zum durchreichen zur Auswahl hat.

DerTom246 said:
Kennst Du eine gute Quelle, wo ich genaueres über multi-queue lesen (how-to?) Mr. Google ist da eher zurückhaltend, wenn es um 'Proxmox multi-queue' geht.

Wenn ich das richtig verstanden habe muss:
1.) die NIC Multiqueue unterstützen
2.) Multiqueue über Konfigs auf Treiberebene auf dem Host selbst aktiviert werden
3.) Multiqueue über das Proxmox WebGUI für alle Virtio NICs aktiviert werden
4.) in jeder VM selbst noch Multiqueue aktiviert werden

Bei mir war es schon daran gescheitert, dass ich nicht herausfinden konnte, wieviele vCPUs meine Intel-NICs und Mellanox-NICs unterstützen oder ob die es überhaupt unterstützen. Im Handbuch und Datenblatt konnte ich jedenfalls nichts finden.

DerTom246 said:
Da der SLOG auf insgesamt 2 SSDs (mirror) liegt, hatte ich nicht gedacht, dass der Performanceeinbruch so gewaltig ist. Auch jetzt mit der 'richtigen CPU' für die VM reduziert sich der Durchsatz auf unter 50% (ca. 110 MB/s).

Sync Writes schreiben alles 2 mal. Erstmal in den ZIL+RAM und dann später nochmal richtig auf die Platten. Wenn du eine SSD als SLOG eingerichtet hast, dann liegt da der ZIL drauf und die Daten gehen erst in den RAM+SLOG und dann auf die Platten. Hast du kein SLOG ist der ZIL auf den Platten selbst und bei Sync Writes wird dann alles erst einmal auf den ZIL auf den Platten geschrieben, dann später dann noch einmal auf die Platten.

Bei Async Writes ist das egal. Da geht es in den RAM und vom RAM direkt auf die Platten. Da dort kein ZIL benutzt wird ist auch der SLOG unbenutzt.
Der Punkt ist aber der, dass da ein Async Write auf deine HDDs schneller sein kann als ein Sync Write auf deine SSD.

DerTom246 · Feb 23, 2021

Dunuin said:
Das mit dem SR-IOV ist garnicht so leicht. Meine ConnectX3 scheint das z.B. zu können und die 1-Port NIC kann dann bis zu 64 Virtuelle Funktionen bereitstellen. Man hat dann quasi bis zu 64 NICs die man per PCI passthrough an die VMs durchreichen kann. Ist dann quasi so als hätte ich eine 64 Port NIC die sich aber einen Anschluss teilen (was ja aber mit tagged vlan nicht so das Problem wäre).
Es ist aber bei Mellanox unglaublich kompliziert und umständlich das SR-IOV überhaupt aktiviert zu bekommen. Egal welche Firmware-Version ich nehme, ich kann das SR-IOV zwar beim Booten in der Firmware der NIC sehen und aktivieren, es lässt sich dann aber wegen Bugs nicht speichern. Will ich das aktivieren muss ich per Tool die Konfigs von der ConnectX3 dumpen, dann per hand die Konfig-Datei umschreiben und die geänderte Konfig-Datei dann zurück auf die NIC flashen. Offizielle Infos dazu sind auch ziemlich spärlich.
Und dann muss das BIOS, Chipsatz und CPU auch erst SR-IOV unterstützen. Einfach nur IOMMU reicht da nicht. Bei meinem einen Mainboard mit 2600er Xeon würde SR-IOV z.B. gehen, bei dem billigeren Mainboard mit 1600er Xeon geht es dann wieder nicht, weil das wohl ein Feature ist, was den Mehrprozessor-CPUs vorbehalten ist.
Wenn ich das richtig verstanden habe und man erst einmal SR-IOV komplett zum laufen bekommen hat, dann kann man das wohl ganz normal per PCI Passthrough durchreichen. Nur das man dann halt nicht nur 1 sondern bis zu 64 "NICs" zum durchreichen zur Auswahl hat.

Ich habe gestern mit der SR-IOV-Konfiguration begonnen. Nach der Anleitung, die ich gefunden habe (https://www.reddit.com/r/Proxmox/comments/cm81tc/tutorial_enabling_sriov_for_intel_nic_x550t2_on), habe ich mir 5 virtuelle NICs erstellt. Die Konfiguration bzw. Zuweisung zu den VMs kommt als nächstes. War gestern froh, dass ich diesen ersten Schritt geschafft habe. Ich habe die Mellanox allerdings gegen eine Intel getauscht. Wenn ich die einzelnen Schritte richtig verstehe, dann macht danach die Netzwerkkarte doch eigentlich wenig bis nichts, wird alles im Rahmen Linux/Kernel konfiguriert. Müsste das nicht auch bei einer Mellanox-Karte funktionieren?

Dunuin · Feb 23, 2021

DerTom246 said:
Ich habe gestern mit der SR-IOV-Konfiguration begonnen. Nach der Anleitung, die ich gefunden habe (https://www.reddit.com/r/Proxmox/comments/cm81tc/tutorial_enabling_sriov_for_intel_nic_x550t2_on), habe ich mir 5 virtuelle NICs erstellt. Die Konfiguration bzw. Zuweisung zu den VMs kommt als nächstes. War gestern froh, dass ich diesen ersten Schritt geschafft habe. Ich habe die Mellanox allerdings gegen eine Intel getauscht. Wenn ich die einzelnen Schritte richtig verstehe, dann macht danach die Netzwerkkarte doch eigentlich wenig bis nichts, wird alles im Rahmen Linux/Kernel konfiguriert. Müsste das nicht auch bei einer Mellanox-Karte funktionieren?

Über Proxmox muss man dann nicht mehr viel machen. Konfigurieren der durchgereichten NIC macht man dann ja im Gast. Das Problem ist eher die Mellanox überhaupt erst dazu zu bekommen, dass die einem SR-IOV erlaubt. Und selbst wenn man das geschafft hat muss die Hardware dann ja noch SR-IOV können. Bei dem einen Server bringt mir das z.B. nichts, weil das BIOS vom Mainboard einfach kein SR-IOV kann, weil das den teureren Server-Boards vorbehalten ist.

DerTom246 · Feb 24, 2021

Auch wenn das jetzt hier etwas off-topic ist...

Hinsichtlich sr-iov habe ich die virtuellen NICs so konfiguriert, wie ich es auch für die echte Netzwerkkarte gemacht habe. Also die beiden virutellen NICs zu einem Bond vereinigt und eine Linux-Bridge für diesen Bond erzeugt. Diesen habe ich dann der VM durchgereicht.

Das Problem ist nun, dass die virtuellen NICs bei mir als inaktiv gekennzeichnet sind und damit auch keine IP erhalten. Muss ich, um die virtuellen NICs nutzen zu können, die echte Karte mit den beiden echten NICs auf die blacklist setzen bzw. deaktivieren?

Dunuin · Feb 24, 2021

DerTom246 said:
Auch wenn das jetzt hier etwas off-topic ist...

Hinsichtlich sr-iov habe ich die virtuellen NICs so konfiguriert, wie ich es auch für die echte Netzwerkkarte gemacht habe. Also die beiden virutellen NICs zu einem Bond vereinigt und eine Linux-Bridge für diesen Bond erzeugt. Diesen habe ich dann der VM durchgereicht.

Das Problem ist nun, dass die virtuellen NICs bei mir als inaktiv gekennzeichnet sind und damit auch keine IP erhalten. Muss ich, um die virtuellen NICs nutzen zu können, die echte Karte mit den beiden echten NICs auf die blacklist setzen bzw. deaktivieren?

Ähm...mit virtuellen NICs meist du virtio NICs?
Wenn du SR-IOV nutzt, dann nutzt du überhaupt keine Bridges, Bonds oder virtuelle NICs.
Dann reichst du per PCI passthrough eine der virtuellen Funktionen der physischen NIC an eine VM durch und die VM hat dann direkten Zugriff auf die physische NIC.
Halt das gleiche wie würdest du eine GPU oder normale NIC per PCI passthrough an eine VM durchreichen.

DerTom246 · Feb 24, 2021

Dunuin said:
Ähm...mit virtuellen NICs meist du virtio NICs?
Wenn du SR-IOV nutzt, dann nutzt du überhaupt keine Bridges, Bonds oder virtuelle NICs.
Dann reichst du per PCI passthrough eine der virtuellen Funktionen der physischen NIC an eine VM durch und die VM hat dann direkten Zugriff auf die physische NIC.
Halt das gleiche wie würdest du eine GPU oder normale NIC per PCI passthrough an eine VM durchreichen.

Mit den virtuellen NICs habe ich die (fünf) virtuellen Netzwerkports der Netzwerkkarte gemeint. Also ens20f0v0 bis ens20f0v4 und ens20f1v0 bis ens20f1v4. Ziel ist bei mir unverändert, dass ich jeweils die beiden v0, v1 etc. als Netzwerkbond nutze. Somit gedenke ich aus einem Bond dann fünf zu machen, die ich dann einzeln an die VMs durchreiche.

Wenn ich das richtig sehe, dann muss der Bond auf Proxmox-Seite bestehen, damit Proxmox Kenntnis davon hat, dass die beiden zusammen gehören. Die Bridge brauche ich doch dann, um den Bond zur VM zu kriegen?

NIC Bonding - Performanceprobleme

Active Member

Distinguished Member

Renowned Member

Active Member

Renowned Member

Active Member

Well-Known Member

Active Member

Well-Known Member

Distinguished Member

Active Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member

Distinguished Member

Active Member