Virtuelle Festplatte sehr langsam

[limone]

Hi,

mir wurde ja geraten kein ZFS RAID zu machen, daher habe ich nun eine Icy Box IB-RD3621U3, da drin 2x 4TB WD Red im RAID1.
Soweit so gut, direkt am Proxmox System ist das ganze auch recht flott, wenn man mit hdparm bzw dd testet (ohne cache natürlich) dann komme ich auch auf gute werden um die 180 MB/s.
Allerdings, sobald ich das ganze in Proxmox als Storage einbinde (lvm-thin) und dann eine virtuelle Festplatte erstelle, hat die VM dahinter gar keinen Spaß damit.
dd ergibt nur ~20MB/s im schreiben, lesen habe ich gar nicht erst getestet.
Ich habe mit allen möglichen Einstellungen herumgespielt, cache, discard oder bus/device, geholfen hat alles nicht so wirklich.
Hat jemand eine Idee was ich tun muss, damit ich auch ordentliche Geschwindigkeiten (100MB/s+) in den VMs bekomme?

System:
i3 5010U
8GB RAM
Proxmox 6.0

 

[LnxBil]

Bitte nur mit fio testen, hdparm und dd sind keine Tests.

Etwas mehr Informationen zu "allen möglichen Einstellungen" bitte. Normalerweise sind die Einstellungen bereits top wenn du das korrekte Betriebssystem auswählst, von daher wäre es noch interessant welches Gast-Betriebssystem du überhaupt verwendest.

 

[udo]

Hi,
ich würde mal vermuten, dass es entweder an der usb-3 performance liegt, oder an der Raidperformance selber.
Und mit 5400 U/min im Raid-1 ist so ziemlich worst case...

Udo

 

[limone]

Bitte nur mit fio testen, hdparm und dd sind keine Tests.

Es würde mir wirklich weiterhelfen, wenn du das begründen könntest. Bloße Aussagen mag ich nicht so gerne einfach hinnehmen..
Bei dd kann ich doch genau so 4k/64k/1m blöcke einstellen, und komme da auf die exakt selben Benchmark werte.


4K

Spoiler: fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_bas ed --name seq_read --filename=/dev/sdb

seq_read: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1             
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=24.3MiB/s][r=6221 IOPS][eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=14449: Thu Aug 29 18:29:47 2019
  read: IOPS=6149, BW=24.0MiB/s (25.2MB/s)(1441MiB/60001msec)
    slat (usec): min=5, max=375, avg= 9.03, stdev= 3.90
    clat (usec): min=3, max=28131, avg=152.21, stdev=74.50
     lat (usec): min=120, max=28141, avg=161.36, stdev=74.72
    clat percentiles (usec):
     |  1.00th=[  145],  5.00th=[  147], 10.00th=[  147], 20.00th=[  149],
     | 30.00th=[  149], 40.00th=[  149], 50.00th=[  149], 60.00th=[  151],
     | 70.00th=[  151], 80.00th=[  153], 90.00th=[  159], 95.00th=[  163],
     | 99.00th=[  188], 99.50th=[  194], 99.90th=[  225], 99.95th=[  285],
     | 99.99th=[ 1319]
   bw (  KiB/s): min=21104, max=25224, per=99.99%, avg=24593.76, stdev=700.55, samples=119
   iops        : min= 5276, max= 6306, avg=6148.42, stdev=175.14, samples=119
  lat (usec)   : 4=0.01%, 20=0.01%, 50=0.01%, 100=0.01%, 250=99.94%
  lat (usec)   : 500=0.04%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=2.43%, sys=7.99%, ctx=368991, 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=368955,0,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):
   READ: bw=24.0MiB/s (25.2MB/s), 24.0MiB/s-24.0MiB/s (25.2MB/s-25.2MB/s), io=1441MiB (1511MB), run=60001-60001msec

Disk stats (read/write):
  sdb: ios=368265/0, merge=0/0, ticks=56528/0, in_queue=156, util=99.72%

64K

Spoiler: fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=64K --numjobs=1 --iodepth=1 --runtime=60 --time_bas ed --name seq_read --filename=/dev/sdb

seq_read: (g=0): rw=read, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=181MiB/s][r=2897 IOPS][eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=16722: Thu Aug 29 18:45:02 2019
  read: IOPS=2910, BW=182MiB/s (191MB/s)(10.7GiB/60001msec)
    slat (usec): min=8, max=4080, avg=16.44, stdev=12.38
    clat (usec): min=4, max=45364, avg=325.31, stdev=216.78
     lat (usec): min=258, max=45376, avg=341.93, stdev=217.00
    clat percentiles (usec):
     |  1.00th=[  265],  5.00th=[  281], 10.00th=[  281], 20.00th=[  289],
     | 30.00th=[  293], 40.00th=[  297], 50.00th=[  302], 60.00th=[  306],
     | 70.00th=[  310], 80.00th=[  326], 90.00th=[  343], 95.00th=[  355],
     | 99.00th=[ 1020], 99.50th=[ 1029], 99.90th=[ 1074], 99.95th=[ 1975],
     | 99.99th=[10159]
   bw (  KiB/s): min=170752, max=196992, per=99.97%, avg=186237.98, stdev=6518.73, samples=119
   iops        : min= 2668, max= 3078, avg=2909.97, stdev=101.86, samples=119
  lat (usec)   : 10=0.01%, 250=0.02%, 500=97.15%, 750=0.30%, 1000=1.06%
  lat (msec)   : 2=1.42%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=1.65%, sys=7.16%, ctx=174683, majf=0, minf=29
  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=174654,0,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):
   READ: bw=182MiB/s (191MB/s), 182MiB/s-182MiB/s (191MB/s-191MB/s), io=10.7GiB (11.4GB), run=60001-60001msec

Disk stats (read/write):
  sdb: ios=174319/0, merge=0/0, ticks=56649/0, in_queue=300, util=99.51%

1M

Spoiler: fio --ioengine=libaio --direct=1 --sync=1 --rw=read --bs=1M --numjobs=1 --iodepth=1 --runtime=60 --time_based --name seq_read --filename=/dev/sdb

seq_read: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=186MiB/s][r=186 IOPS][eta 00m:00s]
seq_read: (groupid=0, jobs=1): err= 0: pid=15054: Thu Aug 29 18:33:48 2019
  read: IOPS=182, BW=183MiB/s (192MB/s)(10.7GiB/60002msec)
    slat (usec): min=66, max=380, avg=85.28, stdev=17.82
    clat (usec): min=2539, max=50327, avg=5374.03, stdev=664.57
     lat (usec): min=2611, max=50404, avg=5460.01, stdev=663.83
    clat percentiles (usec):
     |  1.00th=[ 4752],  5.00th=[ 4817], 10.00th=[ 4883], 20.00th=[ 4948],
     | 30.00th=[ 5014], 40.00th=[ 5145], 50.00th=[ 5407], 60.00th=[ 5538],
     | 70.00th=[ 5669], 80.00th=[ 5735], 90.00th=[ 5866], 95.00th=[ 6063],
     | 99.00th=[ 6128], 99.50th=[ 7242], 99.90th=[ 8979], 99.95th=[11469],
     | 99.99th=[23987]
   bw (  KiB/s): min=167936, max=198656, per=99.99%, avg=187357.87, stdev=6094.95, samples=120
   iops        : min=  164, max=  194, avg=182.97, stdev= 5.95, samples=120
  lat (msec)   : 4=0.10%, 10=99.85%, 20=0.04%, 50=0.01%, 100=0.01%
  cpu          : usr=0.15%, sys=1.94%, ctx=10981, majf=0, minf=268
  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=10979,0,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):
   READ: bw=183MiB/s (192MB/s), 183MiB/s-183MiB/s (192MB/s-192MB/s), io=10.7GiB (11.5GB), run=60002-60002msec

Disk stats (read/write):
  sdb: ios=21927/0, merge=0/0, ticks=88485/0, in_queue=44132, util=99.60%

demnach würde ich mal ganz groß die behauptung aufstellen, wenn ich in proxmox einen lvm-thin pool anlege hat der standardmäßig eine blocksize von 4k?
Bereits bei 64k erreiche ich meine vollen 180 mb/s.
Kann ich also unter proxmox das lvm thin irgendwie mit einer blocksize von 64k einrichten, oder muss man das erst im OS der VM machen?

Etwas mehr Informationen zu "allen möglichen Einstellungen" bitte. Normalerweise sind die Einstellungen bereits top wenn du das korrekte Betriebssystem auswählst, von daher wäre es noch interessant welches Gast-Betriebssystem du überhaupt verwendest.

Naja was man halt so auswählen kann: alle Cache arten und Discard.
Gast OS ist egal, ist bei Windows sowie Debian/Ubuntu so, aber die Ursache habe ich ja schon in den Benchmarks gezeigt.

Hi,
ich würde mal vermuten, dass es entweder an der usb-3 performance liegt, oder an der Raidperformance selber.
Und mit 5400 U/min im Raid-1 ist so ziemlich worst case...

Udo

Die Performance via USB 3 ist top, wie ich ja bereits in meinem Anfangspost geschrieben habe. (Bzw. mehr als ich erwartet hätte, daher für mich top)
Warum ist das worst case? So ziemlich jedes 2-Bay NAS hat diese Konstellation...

Edit:
lvm-thin hat unter proxmox ja schon 64k chunk size, bei meinem RAID sogar 2m, ich denke dann werde ich es wohl in der VM auf 2m setzen, oder spricht was dagegen? 64k würden ja theoretisch reichen.
Das komische ist, wenn ich fio in der VM mache mit 2m block size bekomme ich 1230 mb/s sekunden, was ja irgendwie nicht ganz stimmen kann. cache ist deaktiviert in proxmox.

 

[udo]

Es würde mir wirklich weiterhelfen, wenn du das begründen könntest. Bloße Aussagen mag ich nicht so gerne einfach hinnehmen..
Bei dd kann ich doch genau so 4k/64k/1m blöcke einstellen, und komme da auf die exakt selben Benchmark werte.

Hi,
die "bloße Aussage" von LnxBil kommt nach meiner Meinung daher, weil "messungen" mit dd nicht für alle Storage-Type vergleichbar sind.
So wird bei zfs z.b. komprimiert - und mit dd aus /dev/zero auf ein zfs-Filesystem zu schreiben, bringt zwar tolle Werte, aber die haben nichts mit der Realität zu tun.Und das lesen int noch viel besser!

...

demnach würde ich mal ganz groß die behauptung aufstellen, wenn ich in proxmox einen lvm-thin pool anlege hat der standardmäßig eine blocksize von 4k?
Bereits bei 64k erreiche ich meine vollen 180 mb/s.
Kann ich also unter proxmox das lvm thin irgendwie mit einer blocksize von 64k einrichten, oder muss man das erst im OS der VM machen?

Für reines Lesen und Schreiben von großen zusammenhängenden Datenblöcken bringt es sicherlich ein Vorteil. ABER wenn Du kleine Schreiboperationen machst, muss dafür der gesammte Block gelesen werden, die Änderung eingefügt und der ganze Block wieder geschrieben werden (dies bezieht sich auf Blocksize beim Raid-Level).
Dass heisst Du verlierst gerade bei kleinen Operation Performance - und am 4K-Test siehst Du es ja, dass da die Geschwindigkeit eh nicht überzeugend ist.

Die Performance via USB 3 ist top, wie ich ja bereits in meinem Anfangspost geschrieben habe. (Bzw. mehr als ich erwartet hätte, daher für mich top)
Warum ist das worst case? So ziemlich jedes 2-Bay NAS hat diese Konstellation...

Nur weil ziemlich jedes 2-Bay Nas diesen Raid-Level macht, heisst es nicht dass er besonders gut ist... denn Raid-0 ist Harikiri und mehr geht nicht mit zwei Platten. Ist also eher Zwang als ein Qualitätsmerkmal.
Siehe auch hier: https://de.wikipedia.org/wiki/RAID?section=52#RAID_1 (Wo die Tabelle mit der Performance ist).
Klar setzte ich auch Raid-1 ein - aber nicht mit 5400er Platten, normalerweise mit einer BBU, die die Write-Performance boosted, und auch nicht für IO-hungrigen VMs (bzw. sonst mit SSDs (Datacenter Versionen)).

Udo

 

[LnxBil]

Es würde mir wirklich weiterhelfen, wenn du das begründen könntest. Bloße Aussagen mag ich nicht so gerne einfach hinnehmen..

Das was @udo sagt + dd und hdparm testen single thread sequential, was du in der Praxis nur bei Corner-Cases wie Videostreaming hast, jedes andere Profil involviert random read/write mit mehreren Threads. Enterprise SSDs sind z.B. optimiert für den parallelen, randomisierte Zugriff und du wirst bei einem Test zwischen einer guten und einer schlechten SATA SSD bei sequentiellen Tests nur minimale Unterschiede sehen, beim randomisierten Test aber Unterschiede mit Faktor 1000 oder mehr.

Der von mir und vielen anderen oft geteilte Link zum Thema SSD-Performance ist der hier:

http://www.sebastien-han.fr/blog/20...-if-your-ssd-is-suitable-as-a-journal-device/

Da sieht man sehr stark wie sehr "schlechte" bzw. für die diesen Zweck verwendbare SSDs total abkacken.

 

[limone]

Leider bringt es auch nichts im OS die blocksize auf 64k zu stellen, wahrscheinlich weil das lvm darunter dann trotzdem nur 4k schreibt.