ZFS-Mirror: sehr schlechte IO-Performance

[Patric P]

Hi, wir haben einen neuen Server bestellt (AMD EPYC 7402, 128GB RAM, 2x SAMSUNG MZQL2960HCJR-00A07). Als Dateisystem setzen diesmal auf ZFS als Mirror:

NAME                                                  SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool                                                 888G  37.2G   851G        -         -     6%     4%  1.00x    ONLINE  -
  mirror                                              888G  37.2G   851G        -         -     6%  4.19%      -    ONLINE
    nvme-eui.36344630529079040025384500000001-part3      -      -      -        -         -      -      -      -    ONLINE
    nvme-eui.36344630529078970025384500000001-part3      -      -      -        -         -      -      -      -    ONLINE

Der Server soll den alten Server ersetzen, dort kommt ein HW-Raid10 mit 4 SSDs zum Einsatz.
Unser Problem ist: Die IO Performance mit FIO gemessen ist sehr schlecht:

#fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=4G --readwrite=randrw   test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [m(1)][95.8%][r=62.2MiB/s,w=61.9MiB/s][r=15.9k,w=15.8k IOPS][eta 00m:02s]
test1: (groupid=0, jobs=1): err= 0: pid=353148: Mon Mar 21 20:33:42 2022
  read: IOPS=11.2k, BW=43.8MiB/s (45.9MB/s)(2049MiB/46769msec)
   bw (  KiB/s): min=34352, max=90696, per=98.63%, avg=44255.60, stdev=8943.60, samples=93
   iops        : min= 8588, max=22674, avg=11063.89, stdev=2235.89, samples=93
  write: IOPS=11.2k, BW=43.8MiB/s (45.9MB/s)(2047MiB/46769msec); 0 zone resets
   bw (  KiB/s): min=34328, max=89760, per=98.60%, avg=44185.13, stdev=8767.96, samples=93
   iops        : min= 8582, max=22440, avg=11046.28, stdev=2191.99, samples=93
  cpu          : usr=2.05%, sys=84.00%, ctx=16481, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=524625,523951,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=43.8MiB/s (45.9MB/s), 43.8MiB/s-43.8MiB/s (45.9MB/s-45.9MB/s), io=2049MiB (2149MB), run=46769-46769msec
  WRITE: bw=43.8MiB/s (45.9MB/s), 43.8MiB/s-43.8MiB/s (45.9MB/s-45.9MB/s), io=2047MiB (2146MB), run=46769-46769msec

Auf den VMs ist es im Prinzip dasselbe Bild. Laut iotop wird aber mit 1700-2000m/s auf die Platte geschrieben. Inzwischen habe ich viel zu dem Thema gelesen und weiß, dass es mit ZFS einen overhead beim Schreiben gibt, doch nirgends decken sich die Zahlen mit den schlechten Werten, die wir hier haben.

Wir machen uns nun Sorgen, dass die Performance unter dem ZFS allgemein leidet, insbesondere die der DB (läuft in einer VM). Ich habe auch schon mit dem recordsize Wert experimentiert, doch selbst wenn ich den auf 4k setze, ändert sich in den VMs nichts.
Gibt es Einstellungen, die wir noch ändern können? Oder ist die Sorge unbegründet und es ist eher ein benchmark-Problem?
Wir überlegen derzeit stark, ob wir wieder auf ein Raid1 wechseln.

p#pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.13.19-6-pve)
pve-manager: 7.1-11 (running version: 7.1-11/8d529482)
pve-kernel-helper: 7.1-13
pve-kernel-5.13: 7.1-9
pve-kernel-5.13.19-6-pve: 5.13.19-14
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 15.2.15-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-5
libpve-guest-common-perl: 4.1-1
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.1-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-2
proxmox-backup-client: 2.1.5-1
proxmox-backup-file-restore: 2.1.5-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-7
pve-cluster: 7.1-3
pve-container: 4.1-4
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-6
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.2.0-2
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-1
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1

 

[Falk R.]

Ich habe letztens ähnliche NVMe getestet, da hatte ich im Read 1,2 Mio IOs und Write 180k wie laut Specs erreicht. Also am ZFS kann es nicht liegen. Ich hatte das System zum testen mit Firmware komplett aktuell gemacht und wegen der AMD CPU habe ich den 5.15 Kernel zum testen genutzt. Wenn du noch am testen bist, probiere mal den aktuellen Kernel und guck ob die Firmware im System aktuell ist.
P.S wie sind die NVMe angebunden? Direkt PCI auf dem Board oder ist noch eine Komponente dazwischen?

 

[Dunuin]

Inzwischen habe ich viel zu dem Thema gelesen und weiß, dass es mit ZFS einen overhead beim Schreiben gibt, doch nirgends decken sich die Zahlen mit den schlechten Werten, die wir hier haben.

Wir machen uns nun Sorgen, dass die Performance unter dem ZFS allgemein leidet, insbesondere die der DB (läuft in einer VM). Ich habe auch schon mit dem recordsize Wert experimentiert, doch selbst wenn ich den auf 4k setze, ändert sich in den VMs nichts.

Recordsize ist nur für Datasets. VMs benutzen aber Zvols und da wird ausschließlich die volblocksize benutzt und die Recordsize ignoriert.

 

[Patric P]

Interessant und gut zu wissen.
ashift ist 12

Angebunden werden sie direkt am board sein. Es ist dieses Gehäuse/Board:
https://servers.asus.com/products/servers/rack-servers/RS500A-E11-RS12U

Und die IOs auf z.B. der mysql-kvm ist wirklich gruselig:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=4G --readwrite=randrw
test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.16
Starting 1 process
test1: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=82.4MiB/s,w=82.6MiB/s][r=21.1k,w=21.2k IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=2362: Tue Mar 22 08:04:30 2022
  read: IOPS=7423, BW=28.0MiB/s (30.4MB/s)(2049MiB/70667msec)
   bw (  KiB/s): min= 6747, max=34200, per=46.73%, avg=13877.67, stdev=5155.72, samples=139
   iops        : min= 1686, max= 8550, avg=3469.00, stdev=1289.00, samples=139
  write: IOPS=7414, BW=28.0MiB/s (30.4MB/s)(2047MiB/70667msec); 0 zone resets
   bw (  KiB/s): min= 6882, max=34944, per=46.72%, avg=13856.85, stdev=5105.24, samples=139
   iops        : min= 1720, max= 8736, avg=3463.83, stdev=1276.38, samples=139
  cpu          : usr=1.82%, sys=5.79%, ctx=26950, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=524625,523951,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=28.0MiB/s (30.4MB/s), 28.0MiB/s-28.0MiB/s (30.4MB/s-30.4MB/s), io=2049MiB (2149MB), run=70667-70667msec
  WRITE: bw=28.0MiB/s (30.4MB/s), 28.0MiB/s-28.0MiB/s (30.4MB/s-30.4MB/s), io=2047MiB (2146MB), run=70667-70667msec

Disk stats (read/write):
    dm-0: ios=520350/519666, merge=0/0, ticks=2189076/2195488, in_queue=4384564, util=99.79%, aggrios=524625/524004, aggrmerge=0/52, aggrticks=2187947/2196297, aggrin_queue=2335804, aggrutil=99.72%
  sda: ios=524625/524004, merge=0/52, ticks=2187947/2196297, in_queue=2335804, util=99.72%

 

[Patric P]

Das ist nun mit dem 5.15 Kernel. Der hat leider - so weit ich es sehe - keinen Unterschied gebracht.

 

[Falk R.]

Der ASUS Server ist Standard und den sehe ich öfters bei Kunden. Da sind keine Probleme bekannt.
Kannst du das ZFS mal auflösen und per LVM testen. Damit können wir sehen ob es an der Hardware oder Software liegt.

 

[fireon]

Ich hab hier mal bei mir getestet auf dem SSD-Pool im Raid1 mit einer BS von 1M und natürlich ein Schreibtest.

fio --ioengine=psync --direct=1 --sync=1 --rw=write --bs=1M --numjobs=1 --iodepth=1 --runtime=60 --time_based --name write_1M --filename=/ssd-pool/test/testfile3 --size=10G
write_1M: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.25
Starting 1 process
write_1M: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=294MiB/s][w=294 IOPS][eta 00m:00s]
write_1M: (groupid=0, jobs=1): err= 0: pid=3535479: Tue Mar 22 14:54:20 2022
  write: IOPS=288, BW=289MiB/s (303MB/s)(16.9GiB/60004msec); 0 zone resets
    clat (usec): min=3031, max=13343, avg=3432.48, stdev=255.54
     lat (usec): min=3058, max=13354, avg=3458.32, stdev=256.28
    clat percentiles (usec):
     |  1.00th=[ 3163],  5.00th=[ 3195], 10.00th=[ 3228], 20.00th=[ 3261],
     | 30.00th=[ 3294], 40.00th=[ 3326], 50.00th=[ 3359], 60.00th=[ 3458],
     | 70.00th=[ 3523], 80.00th=[ 3589], 90.00th=[ 3654], 95.00th=[ 3752],
     | 99.00th=[ 4359], 99.50th=[ 4686], 99.90th=[ 5866], 99.95th=[ 6390],
     | 99.99th=[ 8586]
   bw (  KiB/s): min=276480, max=313344, per=100.00%, avg=295875.76, stdev=10813.43, samples=119
   iops        : min=  270, max=  306, avg=288.94, stdev=10.56, samples=119
  lat (msec)   : 4=97.84%, 10=2.16%, 20=0.01%
  cpu          : usr=0.92%, sys=10.72%, ctx=42580, majf=7, minf=9
  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,17336,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=289MiB/s (303MB/s), 289MiB/s-289MiB/s (303MB/s-303MB/s), io=16.9GiB (18.2GB), run=60004-60004msec
fio --ioengine=psync --direct=1 --sync=1 --rw=write --bs=1M --numjobs=1        0,97s user 6,58s system 12% cpu 1:00,36 total

Das ganze nun mit 4k ist ähnlich. Die Frage ist ob du wirklich Files kleiner als 1M pflegst. Im Betrieb hier merk ich hier keine Performanceprobleme. Auch beim Kunden fahren wir SQL Datenbanken um 200GB. Dort haben wir aber auch 4 bis 8 SSD's verbaut. Oder gleich 2 NVMe's so wie das schon richtig gemacht hast.

fio --ioengine=psync --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --name write_1M --filename=/ssd-pool/test/testfile4 --size=4G
write_1M: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.25
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=22.2MiB/s][w=5685 IOPS][eta 00m:00s]
write_1M: (groupid=0, jobs=1): err= 0: pid=3600253: Tue Mar 22 14:58:41 2022
  write: IOPS=5226, BW=20.4MiB/s (21.4MB/s)(1225MiB/60001msec); 0 zone resets
    clat (usec): min=134, max=38379, avg=190.07, stdev=237.57
     lat (usec): min=135, max=38380, avg=190.27, stdev=237.58
    clat percentiles (usec):
     |  1.00th=[  151],  5.00th=[  157], 10.00th=[  161], 20.00th=[  165],
     | 30.00th=[  169], 40.00th=[  174], 50.00th=[  178], 60.00th=[  182],
     | 70.00th=[  186], 80.00th=[  194], 90.00th=[  210], 95.00th=[  231],
     | 99.00th=[  334], 99.50th=[  750], 99.90th=[ 2114], 99.95th=[ 2474],
     | 99.99th=[ 2835]
   bw (  KiB/s): min=17304, max=23056, per=100.00%, avg=20918.03, stdev=1051.44, samples=119
   iops        : min= 4326, max= 5764, avg=5229.50, stdev=262.86, samples=119
  lat (usec)   : 250=97.13%, 500=2.25%, 750=0.12%, 1000=0.21%
  lat (msec)   : 2=0.18%, 4=0.11%, 10=0.01%, 50=0.01%
  cpu          : usr=0.99%, sys=16.69%, ctx=628927, majf=0, minf=13
  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,313599,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=20.4MiB/s (21.4MB/s), 20.4MiB/s-20.4MiB/s (21.4MB/s-21.4MB/s), io=1225MiB (1285MB), run=60001-60001msec
fio --ioengine=psync --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1        1,01s user 10,14s system 18% cpu 1:00,34 total

Gemessen wurden hier zwei Intel D3-S4510.

Laut dem https://semiconductor.samsung.com/ssd/datacenter-ssd/pm9a3/mzql2960hcjr-00a07/ müssten deine MVME's ja voll abgehen.

 

[Patric P]

Hallo, wir haben den Server nun noch einmal mit einem Raid1 aufsetzen lassen und die Benchmark Werte per fio sind deutlich besser:

# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=4G --readwrite=randrw
test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.25
Starting 1 process
test1: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=310MiB/s,w=311MiB/s][r=79.4k,w=79.6k IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=3203: Tue Mar 22 09:17:02 2022
  read: IOPS=78.0k, BW=305MiB/s (320MB/s)(2049MiB/6724msec)
   bw (  KiB/s): min=301984, max=321104, per=100.00%, avg=312526.77, stdev=6641.99, samples=13
   iops        : min=75496, max=80276, avg=78131.69, stdev=1660.50, samples=13
  write: IOPS=77.9k, BW=304MiB/s (319MB/s)(2047MiB/6724msec); 0 zone resets
   bw (  KiB/s): min=300056, max=322472, per=100.00%, avg=312099.08, stdev=7049.09, samples=13
   iops        : min=75014, max=80618, avg=78024.77, stdev=1762.27, samples=13
  cpu          : usr=11.72%, sys=69.75%, ctx=431572, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
     issued rwts: total=524625,523951,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=305MiB/s (320MB/s), 305MiB/s-305MiB/s (320MB/s-320MB/s), io=2049MiB (2149MB), run=6724-6724msec
  WRITE: bw=304MiB/s (319MB/s), 304MiB/s-304MiB/s (319MB/s-319MB/s), io=2047MiB (2146MB), run=6724-6724msec

Disk stats (read/write):
    md1: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=267183/528840, aggrmerge=4942/4979, aggrticks=22828/6483, aggrin_queue=29312, aggrutil=98.15%
  nvme0n1: ios=296535/523969, merge=9885/37, ticks=24917/5468, in_queue=30386, util=98.15%
  nvme1n1: ios=237831/533712, merge=0/9922, ticks=20739/7499, in_queue=28238, util=98.15%

Auf den VMs sind die Werte etwas schlechter.
Doch einer der entscheidenden Tests läuft interessanterweise weniger gut: Per sysbench auf die DB:
Da performte das ZFS - trotz miserabler IO-Werte - besser:

# SQL statistics:
# mit ZFS
SQL statistics:
    queries performed:
        read:                            6915608
        write:                           1975888
        other:                           987944
        total:                           9879440
    transactions:                        493972 (1646.55 per sec.)
    queries:                             9879440 (32930.93 per sec.)

# mit Raid1, LVM
SQL statistics:
    queries performed:
        read:                            5417300
        write:                           1547800
        other:                           773900
        total:                           7739000
    transactions:                        386950 (1289.81 per sec.)
    queries:                             7739000 (25796.10 per sec.)

@fireon
Danke für deine Tests! Insgesamt spielt für uns die blocksize von 1M keine große Rolle, da hauptsächlich kleinere Dateien verarbeitet werden. Insbesondere bei der Datenbank. Doch inwieweit nun der Test mit random 4k eine Rolle spielt - who knows! Auf dem alten Server lief ein RAID 10, dass in diesen FIO-Tests besser abschnitt und es fühlt sich komisch an, wenn der neue Server in diesen benchmarks so deutlich schlechter abschneidet.

Doch aufgrund des SQL-Tests schwanken wir nun wieder und fragen uns, ob es ggf. doch nur ein benchmark-Fehler bzw. eine benchmark-Fehlinterpretation ist. Die Vorteile des ZFS gegenüber dem raid1+LVM sind schon sehr sexy. Insgesamt wird der Server sicher so oder so gut laufen, doch da es eine initiale Weichenstellung ohne Weg zurück ist, versuche ich nun irgendwie im Vorfeld zu klären, welche der beiden Varianten besser für uns ist.

 

[Falk R.]

Hi, irgendwo habt ihr noch die Handbremse angezogen. Ich hatte letztens einen Test mit Kioxia NVMe's gemacht und die hatten fast identische Herstellerangaben zu euren Samsung.
Da hatte ich vor allem auch SQL Workload getestet und der lief echt Top.
Wie sieht denn deine SQL VM aus?

 

[Patric P]

Die sieht so aus:

~#qm config 103
bootdisk: scsi0
cores: 8
cpu: EPYC
ide2: none,media=cdrom
memory: 32768
name: kvm-mysql
net0: virtio=1E:C9:19:39:E0:27,bridge=vmbr1
numa: 0
onboot: 1
ostype: l26
scsi0: local:103/vm-103-disk-0.qcow2,discard=on,iothread=1,size=100G
scsihw: virtio-scsi-single
smbios1: uuid=de69e54f-9672-49b0-ab13-37356cded528
sockets: 2

und der sysbench befehl zum testen der DB ist:
~# sysbench oltp_read_write --db-driver=mysql --threads=8 --max-requests=0 --table-size=1000000 --time=30 --mysql-user=sbtest --mysql-password=[...] --mysql-host=10.42.42.11 run

 

[Falk R.]

Hi, für Performancetests fahre ich immer folgende Konfig:
bootdisk = virtio
Die OS Disk nutze ich nie für tests, Produktiv kommen Datenbanken ja auch immer auf eine separate Disk und natürlich die Logfiles ebenfalls auf eine eigene.
CPU nehme ich immer host, bei homogenen Clustern geht das immer und man kann sicher sein, dass kein Flag maskiert wird.
Wieso hast du iothread=1 gesetzt? Hast du auch mal mit Cache getestet?
Setz mal Sockets auf 1, somit zwingst du den CPU Scheduler bei einem dual Sockel System, immer nur eine CPU zu nutze und den Link zwischen den CPUs außen vor zu lassen. Dein Server hat eh nur ein Sockel, daher bringt dir sockets=2 gar nichts.

Gib der VM mal ne zweite Disk mit virtio und dann teste mal darauf.