Proxmox 6.2 Langsame Schreibgeschwindigkeit Hardware RAID

L

linushstge

Well-Known Member
Dec 5, 2019
77
10
48
Hi zusammen,

folgendes Server Setup:

Avago MEGA RAID SAS LSI 9361i16
SAS SSDs: 16x Samsung PM1643 1,9 TB
RAID Konfiguration: RAID 10 (14x, 2x Hot Spare)

Controller Info:

Code: 
Adapter #0

==============================================================================
                    Versions
                ================
Product Name    : AVAGO MegaRAID SAS 9361-16i
Serial No       : SK01367863
FW Package Build: 24.22.0-0071

                    Mfg. Data
                ================
Mfg. Date       : 04/01/20
Rework Date     : 00/00/00
Revision No     : 34004
Battery FRU     : N/A

                Image Versions in Flash:
                ================
BIOS Version       : 6.36.00.3_4.19.08.00_0x06180203
Ctrl-R Version     : 5.19-0603
FW Version         : 4.740.00-8452
NVDATA Version     : 4.1705.00-00011
Boot Block Version : 3.10.01.00-0004

Code: 
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 12.221 TB
Sector Size         : 512
Is VD emulated      : Yes
Mirror Data         : 12.221 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives per span:2
Span Depth          : 7
Default Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Bad Blocks Exist: No
PI type: No PI

Is VD Cached: No


Number of Dedicated Hot Spares: 2
    0 : EnclId - 252 SlotId - 15
    1 : EnclId - 252 SlotId - 14

Zusammenfassung:

Code: 
-- Controller information --
-- ID | H/W Model                   | RAM    | Temp | BBU    | Firmware
c0    | AVAGO MegaRAID SAS 9361-16i | 2048MB | 55C  | Good   | FW: 24.22.0-0071

-- Array information --
-- ID | Type    |    Size |  Strpsz | Flags | DskCache |   Status |  OS Path | CacheCade |InProgress
c0u0  | RAID-10 |  12221G |  256 KB | RA,WT |  Enabled |  Optimal | /dev/sda | None      |None

-- Disk information --
-- ID    | Type | Drive Model                    | Size     | Status          | Speed    | Temp | Slot ID  | LSI ID
c0u0s0p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:0]  | 10
c0u0s0p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 33C  | [252:1]  | 11
c0u0s1p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:2]  | 9
c0u0s1p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 33C  | [252:3]  | 8
c0u0s2p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:4]  | 14
c0u0s2p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 33C  | [252:5]  | 15
c0u0s3p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:6]  | 13
c0u0s3p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 35C  | [252:7]  | 12
c0u0s4p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:8]  | 2
c0u0s4p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 35C  | [252:9]  | 3
c0u0s5p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 35C  | [252:10] | 1
c0u0s5p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 35C  | [252:11] | 0
c0u0s6p0 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 35C  | [252:12] | 6
c0u0s6p1 | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Online, Spun Up | 12.0Gb/s | 34C  | [252:13] | 7

-- Unconfigured Disk information --
-- ID   | Type | Drive Model                    | Size     | Status              | Speed    | Temp | Slot ID  | LSI ID | Path
c0uXpY  | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Hotspare, Spun Up   | 12.0Gb/s | 33C  | [252:14] | 5      | N/A
c0uXpY  | SSD  | SAMSUNG MZILT1T9HAJQ/007GXF4 T | 1.745 TB | Hotspare, Spun Up   | 12.0Gb/s | 32C  | [252:15] | 4      | N/A




Lesen:
Code: 
root@node04:/# hdparm -T /dev/sda

/dev/sda:
Timing cached reads:   18096 MB in  2.00 seconds = 9058.56 MB/sec


Schreiben:
Code: 
root@node04:/# dd if=/dev/zero of=/root/testfile bs=1G count=10 oflag=direct
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 4.79144 s, 2.2 GB/s

Code: 
root@node04:/# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=572MiB/s,w=191MiB/s][r=146k,w=48.9k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=7386: Wed Jul  8 11:50:47 2020
  read: IOPS=146k, BW=569MiB/s (597MB/s)(3070MiB/5394msec)
   bw (  KiB/s): min=575176, max=586504, per=100.00%, avg=582814.40, stdev=3434.16, samples=10
   iops        : min=143794, max=146626, avg=145703.60, stdev=858.54, samples=10
  write: IOPS=48.7k, BW=190MiB/s (199MB/s)(1026MiB/5394msec); 0 zone resets
   bw (  KiB/s): min=192072, max=196872, per=100.00%, avg=194960.80, stdev=1593.57, samples=10
   iops        : min=48018, max=49216, avg=48740.20, stdev=397.96, samples=10
  cpu          : usr=11.00%, sys=87.11%, ctx=29618, majf=0, minf=10
  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=785920,262656,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=569MiB/s (597MB/s), 569MiB/s-569MiB/s (597MB/s-597MB/s), io=3070MiB (3219MB), run=5394-5394msec
  WRITE: bw=190MiB/s (199MB/s), 190MiB/s-190MiB/s (199MB/s-199MB/s), io=1026MiB (1076MB), run=5394-5394msec

Disk stats (read/write):
    dm-1: ios=782344/261473, merge=0/0, ticks=83384/12328, in_queue=95712, util=98.28%, aggrios=785926/262658, aggrmerge=0/3, aggrticks=83248/12332, aggrin_queue=0, aggrutil=97.45%
  sda: ios=785926/262658, merge=0/3, ticks=83248/12332, in_queue=0, util=97.45%

Die generelle Schreibgeschwindigkeit sollte in der Theorie bei Rund 12.600 MB/s liegen, leider erreiche ich nur rund 2 GB/s.

In einer Windows VM habe ich testweise einmal eine 10 GB von a nach b kopiert und komme auf rund 900 MB/s.
(VirtiO Treiber sind installiert)

Kann hier jemand weiterhelfen?
 
Last edited:
Moin,

die theoretische Schreibgeschwindigkeit die du da errechnest ist verkehrt, da du einfach nur die SSD Leistung addierst, statt die Flaschenhälse auf dem Übertragungsweg zu beachten.

Beispiel: Der Raid Controller ist im Optimalfall via PCIe 3.0 8x angeschlossen und kann damit Brutto Datenraten von 7800 MB/s erreichen. Wie ist der bei dir angebunden?
 
  • Like
Reactions: linushstge and AndrwHmmr
Hi danke für die schnelle Antwort. Ja völlig richtig. Genau, ist auch via PCIe 3.0 8x Width angebunden:

Code: 
86:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS-3 3316 [Intruder] (rev 01)

LnkCap:    Port #0, Speed 8GT/s, Width x8, ASPM L0s, Exit Latency L0s <2us, L1 <4us
LnkSta:    Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

Aber auch der Wert von 7.800 MB/s wird ja nichtmal annähernd erreicht?
 
Last edited:
Aber da hast du noch den Filesystem Overhead, und vielleicht macht auch die CPU vom RAID Controller einfach nicht mehr mit...
2,2GB/s ist für SAS RAID10 schon plenty...

Code: 
root@node04:/# hdparm -T /dev/sda

/dev/sda:
Timing cached reads:   18096 MB in  2.00 seconds = 9058.56 MB/sec
Nimm mal "hdparm -t" kleines -t deaktiviert den Cache und zeigt dir echte Geschwindigkeiten an. Gibt auch noch das Flag
"--direct" auch empfehlenswert.
 
Hi Danke für die Rückmeldung.

Code: 
hdparm -t /dev/sda
Timing buffered disk reads: 6736 MB in  3.00 seconds = 2244.79 MB/sec

hdparm -t --direct /dev/sda
Timing O_DIRECT disk reads: 10560 MB in  3.00 seconds = 3519.80 MB/sec

Bzgl. CPU: Im Hostsystem sind 2x Intel Xeon Silver á 12 Cores, 24 Threads verbaut:

Bildschirmfoto 2020-07-09 um 12.06.49.png



Ich habe inzwischen noch weitere Tests mit FIO gemacht und komme auf folgende Ergebnisse:

Code: 
RANDOM READ DURCHSATZ: ~ 6.3 GB/s
RANDOM READ 4k IOPS: ~ 209.000

RANDOM WRITE DURCHSATZ: ~3.2 GB/s
RANDOM WRITE 4k IOPS: ~ 102.000

Das ganze habe ich einmal testweise mit nur 8 SSD's ausprobiert. Völlig identische Ergebnisse.
Stripe Size 64 KB / 256 KB ebenfalls identische Ergebnisse.

FastPath ist ebenfalls aktiviert und wenn man sich nach dem Lenovo Benchmark im RAID 5 richtet:

Bildschirmfoto 2020-07-09 um 11.59.42.png


Siehe: https://lenovopress.com/lp0592.pdf


Testweise habe ich das identische Setup mal mit einem Adaptec RAID 8805, (der nur 8 Lanes hat) ausprobiert und komme hier beim Einsatz von nur 8 SSDs auf die doppelte Schreibgeschwindigkeit sowie die doppelten IOPS.

Lg Linus
 
Last edited:
Also mir fällt gerade kein schlauer Grund dafür ein, aber ich kann auch kein Beispiel im Netz finden, bei dem ein LSI 9361 mehr als 2 GB/s beim schreiben erreicht.

Mal anders:
Wieso willst du das Ding überhaupt nutzen?
Ich kann gegenüber einer Lösung via ZFS Mirror eigentlich nur Nachteile sehen.


edit: Noch was. Check mal die Temperaturen von dem Ding. Der einzige LSI 9361 den ich bisher genutzt hab wurde brutal heiß (>100 grad) und war ohne aktive Kühlung nicht vernünftig nutzbar (hat immer die Leistung gedrosselt).
 
Generell setzen wir in allen Servern MegaRAIDs ein und sind gerade vom normalen SSD und HDD Bereich sehr zufrieden auch was den WriteBack Cache bei HDD's angeht, daher wollte ich gerne bei Avago / Broadcom bleiben, alleine weil die Controller Konfiguration über megacli gut gelöst ist.

Danke für den Temperatur Tipp. Am Anfang wurde der Controller wirklich ~70°C heiß, aber mit der richtigen Lüfter Config liegt der jetzt bei durchschnittlich 50°C.

Code: 
-- Controller information --
-- ID | H/W Model                   | RAM    | Temp | BBU    | Firmware
c0    | AVAGO MegaRAID SAS 9361-16i | 2048MB | 51C  | Good   | FW: 24.22.0-0071

-- Array information --
-- ID | Type    |    Size |  Strpsz | Flags | DskCache |   Status |  OS Path | CacheCade |InProgress
c0u0  | RAID-10 |  12221G |   64 KB | RA,WT |  Enabled |  Optimal | /dev/sda | None      |None
 
Ich versteh den Wunsch nach einer möglichst einheitlichen Serverumgebung total, aber faktisch lösen Raid Controller nun mal ein Problem, das dank moderner Software und schnellen (NVMe) SSds so gar nicht mehr existiert.

Raid Controller sind inzwischen in etlichen Umgebungen der Flaschenhals schlechthin, da das Konzept nun mal für vergleichsweise langsame HDDs entwickelt wurde und sich nicht so einfach auf schnelle SSDs übertragen lässt.
Es hat seinen Grund, dass es für moderne NVMe SSDs quasi gar keine Raid Controller gibt.

Ich würde mich zumindest langsam an den Gedanken gewöhnen, zukünftige Systeme besser mit einem ZFS Mirror über NVMe SSDs aufzubauen.
Sieh es positiv: Ein Teil weniger das kaputt gehen kann und ein Teil weniger für das Ersatzteile auf Lager sein müssen.
 
  • Like
Reactions: Sourcenux, linushstge and AndrwHmmr
Wie sieht denn die Verkabelung vom RAID Controller zu den Festplatten aus?
Sind alle 4 Stecker am Controller in Verwendung?
 
Du spricht überall immer von random read und random write und die Werte dafür sind doch ziemlich gut. Ich denke, dass du mal sequential read und write (bei mehreren Threads) arbeiten solltest, da wirst du eher an die Grenzen stoßen. Problem ist oft der mehrere-Threads-Ansatz. Ich habe noch kein SSD-System gesehen, dass bei nur einem IO-Thread volle Performance gebracht hat, das ging nur über viele Threads.
 
  • Like
Reactions: AndrwHmmr
Hi, danke für die Rückmeldung.

Gerne anbei einmal die SEQ Tests mit jeweils 10 Threads:

READ 4k SEQ IOPS: 10 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_read.fio --bs=4K --iodepth=64 --size=4G --readwrite=read --numjobs=10

Run status group 0 (all jobs):
   READ: bw=1053MiB/s (1105MB/s), 105MiB/s-106MiB/s (110MB/s-111MB/s), io=40.0GiB (42.9GB), run=38531-38886msec

Disk stats (read/write):
    dm-1: ios=10360983/69, merge=0/0, ticks=1466936/0, in_queue=1466936, util=99.83%, aggrios=10461193/48, aggrmerge=21499/21, aggrticks=1457693/6, aggrin_queue=0, aggrutil=99.56%
  sda: ios=10461193/48, merge=21499/21, ticks=1457693/6, in_queue=0, util=99.56%
~ 264.000 IOPS


WRITE 4k SEQ IOPS: 10 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_write.fio --bs=4K --iodepth=64 --size=4G --readwrite=write --numjobs=10

Run status group 0 (all jobs):
  WRITE: bw=838MiB/s (878MB/s), 83.8MiB/s-83.9MiB/s (87.8MB/s-88.0MB/s), io=40.0GiB (42.9GB), run=48798-48895msec

Disk stats (read/write):
    dm-1: ios=0/10485836, merge=0/0, ticks=0/27997704, in_queue=27997704, util=99.86%, aggrios=60/4781732, aggrmerge=0/5680406, aggrticks=20/12612698, aggrin_queue=0, aggrutil=99.76%
  sda: ios=60/4781732, merge=0/5680406, ticks=20/12612698, in_queue=0, util=99.76%

~ 214.000 IOPS
 
und dann geht bei sequentiell noch in der Blockgröße hoch. Die meiste Last die man so sieht ist ja variabel in der Blockgröße beim Lesen.
 
Und nochmal mit 256K

READ 256k SEQ: 10 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_read.fio --bs=256K --iodepth=64 --size=4G --readwrite=read --numjobs=10

Run status group 0 (all jobs):
   READ: bw=6394MiB/s (6705MB/s), 639MiB/s-646MiB/s (670MB/s-678MB/s), io=40.0GiB (42.9GB), run=6339-6406msec

Disk stats (read/write):
    dm-1: ios=163689/3, merge=0/0, ticks=1777156/0, in_queue=1777156, util=98.45%, aggrios=655360/2, aggrmerge=0/1, aggrticks=6214774/1, aggrin_queue=4901500, aggrutil=97.64%
  sda: ios=655360/2, merge=0/1, ticks=6214774/1, in_queue=4901500, util=97.64%



WRITE 256k SEQ: 10 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_write.fio --bs=256K --iodepth=64 --size=4G --readwrite=write --numjobs=10

Run status group 0 (all jobs):
  WRITE: bw=3267MiB/s (3425MB/s), 327MiB/s-332MiB/s (343MB/s-348MB/s), io=40.0GiB (42.9GB), run=12334-12539msec

Disk stats (read/write):
    dm-1: ios=0/162164, merge=0/0, ticks=0/5118912, in_queue=5118912, util=99.14%, aggrios=12/655366, aggrmerge=0/3, aggrticks=29/12087253, aggrin_queue=10785448, aggrutil=98.45%
  sda: ios=12/655366, merge=0/3, ticks=29/12087253, in_queue=10785448, util=98.45%
 
Wird besser. Geh mal noch weiter hoch mit 16 Threads und 1M Blöcken. Die Größe von 4G brauchst du nicht, denn so wie ich das sehe liest du ja direkt das Blockgerät aus. Vielleicht könnte es mit den Stripes etc. sein, dass nicht alle Disks verwendet werden oder der Controller sonst wie komisches Zeugs macht. Ist glaub ich besser wenn man das gesamt Gerät zur Verfügung hat zum Testen.
 
1M Blöcke 1G Files:

READ 256k SEQ: 16 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_read.fio --bs=1M --iodepth=64 --size=1G --readwrite=read --numjobs=16


Run status group 0 (all jobs):
   READ: bw=6398MiB/s (6708MB/s), 400MiB/s-405MiB/s (419MB/s-425MB/s), io=16.0GiB (17.2GB), run=2526-2561msec

Disk stats (read/write):
    dm-1: ios=15374/5, merge=0/0, ticks=199796/0, in_queue=199796, util=95.88%, aggrios=262144/4, aggrmerge=0/1, aggrticks=2483658/3, aggrin_queue=1953008, aggrutil=91.97%
  sda: ios=262144/4, merge=0/1, ticks=2483658/3, in_queue=1953008, util=91.97%



WRITE 256k SEQ: 16 Threads:
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_write.fio --bs=1M --iodepth=64 --size=1G --readwrite=write --numjobs=16

Run status group 0 (all jobs):
  WRITE: bw=3268MiB/s (3426MB/s), 204MiB/s-210MiB/s (214MB/s-220MB/s), io=16.0GiB (17.2GB), run=4878-5014msec

Disk stats (read/write):
    dm-1: ios=0/15922, merge=0/0, ticks=0/698580, in_queue=698580, util=97.10%, aggrios=12/262146, aggrmerge=0/1, aggrticks=22/4854281, aggrin_queue=4327632, aggrutil=95.37%
  sda: ios=12/262146, merge=0/1, ticks=22/4854281, in_queue=4327632, util=95.37%


Macht es dann ggf. Sinn mal eine noch größere Stripe Size auszuprobieren (512KB)? Die letzten Tests hier sind alle auf der 64KB Stripe Size
 
linushstge said:
Macht es dann ggf. Sinn mal eine noch größere Stripe Size auszuprobieren (512KB)? Die letzten Tests hier sind alle auf der 64KB Stripe Size
Click to expand...

Musst halt schauen, dass du immer eine Blockgröße beim Testen hast, die dem Stripe dann mit der Anzahl der Disks entspricht, sonst hast du ja read amplification, gleiches beim Schreiben.

Und ja, diesen ganzen Raid-Controller-Optimisierungs-Käse hätte man mit ZFS echt nicht :-/
 
  • Like
Reactions: linushstge
LnxBil said:
Musst halt schauen, dass du immer eine Blockgröße beim Testen hast, die dem Stripe dann mit der Anzahl der Disks entspricht, sonst hast du ja read amplification, gleiches beim Schreiben.
Click to expand...
Jap, guter Tipp! Danke


LnxBil said:
Und ja, diesen ganzen Raid-Controller-Optimisierungs-Käse hätte man mit ZFS echt nicht :-/
Click to expand...

Wenn Proxmox mit dem Supermicro NVMe VROC kompatibel wäre, dann wäre es sicher kein MegaRAID mehr geworden :)
https://www.supermicro.com/en/products/nvme
 
LnxBil said:
[..]

Und ja, diesen ganzen Raid-Controller-Optimisierungs-Käse hätte man mit ZFS echt nicht :-/
Click to expand...

Um hier noch einmal anzuknüpfen..

Danke für den Tipp, im neuen Server zum ersten Mal via ZFS Mirror (RAID 10)

Identische fio Tests wie damals mit dem HW RAID:

SEQ READ: 34.2 GiB/s
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_read.fio --bs=1M --iodepth=64 --size=1G --readwrite=read --numjobs=16

Run status group 0 (all jobs):
   READ: bw=34.2GiB/s (36.7GB/s), 2188MiB/s-2197MiB/s (2294MB/s-2304MB/s), io=16.0GiB (17.2GB), run=466-468msec

SEQ Write: 25.9 GiB/s
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=seq_write.fio --bs=1M --iodepth=64 --size=1G --readwrite=write --numjobs=16

Run status group 0 (all jobs):
  WRITE: bw=25.9GiB/s (27.8GB/s), 1657MiB/s-1665MiB/s (1737MB/s-1746MB/s), io=16.0GiB (17.2GB), run=615-618msec

IOPS READ: 590k IOPS
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=iops_read.fio --bs=4K --iodepth=64 --size=1G --readwrite=read --numjobs=16

Jobs: 16 (f=16): [R(16)][100.0%][r=2305MiB/s][r=590k IOPS][eta 00m:00s]

IOPS WRITE: 313k IOPS
Code: 
fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=iops_write.fio --bs=4K --iodepth=64 --size=1G --readwrite=write --numjobs=16

Jobs: 16 (f=16): [W(16)][100.0%][w=1222MiB/s][w=313k IOPS][eta 00m:00s]

Nie wieder HW RAIDS :)
 
Last edited:
  • Like
Reactions: aaron
You must log in or register to reply here.
Top Bottom