Sziasztok!
Kérlek vezessen rá valaki mit néztem be és miért ilyen szörnyen rosszak a sebességek. Adott egy nem mai gyerek HP ProLiant DL20 szerver (E3-1220v5 / 32GB DDR4 UDIMM ECC). Debian 12 alap, Linux 6.8.12-11-pve kernel. Két HDD (WD2000F9YZ-0) és két SSD (WDS500G1R0B). Tudom hogy az SSD-k nem enterprise grade eszközök, de ennél azért többet kellene tudniuk, és a HDD-k esetén is gyanúsan alacsony minden érték. A B140i RAID vezérlő le van tiltva, minden eszköz közvetlenül, AHCI-n elérhető. A partíciók és egyéb hasznos infók:
root@pve:~# fdisk -l
Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD2000F9YZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D5DEFE9B-A29D-614F-BBF3-C31770AD9F27
Device Start End Sectors Size Type
/dev/sdb1 2048 3907012607 3907010560 1.8T Solaris /usr & Apple ZFS
/dev/sdb9 3907012608 3907028991 16384 8M Solaris reserved 1
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WDS500G1R0B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD6F9ED7-CD69-48DD-AE75-2320DA87F794
Device Start End Sectors Size Type
/dev/sdd1 34 2047 2014 1007K BIOS boot
/dev/sdd2 2048 2099199 2097152 1G EFI System
/dev/sdd3 2099200 975175680 973076481 464G Solaris /usr & Apple ZFS
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD2000F9YZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 654222C6-1214-894C-BF2E-9B003371915C
Device Start End Sectors Size Type
/dev/sda1 2048 3907012607 3907010560 1.8T Solaris /usr & Apple ZFS
/dev/sda9 3907012608 3907028991 16384 8M Solaris reserved 1
Disk /dev/sdc: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WDS500G1R0B
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 813FCBF3-4AAD-4531-B964-88E750E044DF
Device Start End Sectors Size Type
/dev/sdc1 34 2047 2014 1007K BIOS boot
/dev/sdc2 2048 2099199 2097152 1G EFI System
/dev/sdc3 2099200 975175680 973076481 464G Solaris /usr & Apple ZFS
==============================
root@pve:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
local-zfs-hdd 552K 1.76T 96K /local-zfs-hdd
rpool 10.9G 435G 104K /rpool
rpool/ROOT 10.9G 435G 96K /rpool/ROOT
rpool/ROOT/pve-1 10.9G 435G 10.9G /
rpool/data 96K 435G 96K /rpool/data
rpool/var-lib-vz 96K 435G 96K /var/lib/vz
==============================
root@pve:~# zpool status
pool: local-zfs-hdd
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
local-zfs-hdd ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD2000F9YZ-09N20L1_WD-WMC1P0D9UMLK ONLINE 0 0 0
ata-WDC_WD2000F9YZ-09N20L1_WD-WMC1P0E6MPP9 ONLINE 0 0 0
errors: No known data errors
pool: rpool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WDS500G1R0B-68A4Z0_244045800382-part3 ONLINE 0 0 0
ata-WDC_WDS500G1R0B-68A4Z0_244045800391-part3 ONLINE 0 0 0
errors: No known data errorsÉs a tesztek. Gyalázatos. Miért?
root@pve:~# fio --name=randwrite_hdd --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --runtime=15 --group_reporting --iodepth=32 --directory=/local-zfs-hdd/fiotest
randwrite_hdd: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=4): [w(4)][9.8%][eta 02m:37s]
randwrite_hdd: (groupid=0, jobs=4): err= 0: pid=15611: Tue Jun 24 15:14:43 2025
write: IOPS=7571, BW=29.6MiB/s (31.0MB/s)(473MiB/15981msec); 0 zone resets
slat (usec): min=5, max=1472.8k, avg=524.55, stdev=22447.00
clat (usec): min=5, max=1517.1k, avg=16377.85, stdev=124716.23
lat (usec): min=510, max=1517.1k, avg=16902.40, stdev=126690.01
clat percentiles (usec):
| 1.00th=[ 676], 5.00th=[ 775], 10.00th=[ 832],
| 20.00th=[ 914], 30.00th=[ 988], 40.00th=[ 1090],
| 50.00th=[ 1205], 60.00th=[ 1369], 70.00th=[ 1631],
| 80.00th=[ 2245], 90.00th=[ 3982], 95.00th=[ 8848],
| 99.00th=[ 859833], 99.50th=[1249903], 99.90th=[1468007],
| 99.95th=[1468007], 99.99th=[1484784]
bw ( KiB/s): min= 4892, max=177312, per=100.00%, avg=65378.60, stdev=13260.11, samples=59
iops : min= 1221, max=44328, avg=16344.35, stdev=3315.10, samples=59
lat (usec) : 10=0.01%, 500=0.01%, 750=3.62%, 1000=28.00%
lat (msec) : 2=45.36%, 4=13.05%, 10=5.27%, 20=1.44%, 50=1.60%
lat (msec) : 100=0.21%, 250=0.11%, 500=0.20%, 1000=0.20%, 2000=0.92%
cpu : usr=0.48%, sys=5.39%, ctx=18019, majf=0, minf=52
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,121008,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=29.6MiB/s (31.0MB/s), 29.6MiB/s-29.6MiB/s (31.0MB/s-31.0MB/s), io=473MiB (496MB), run=15981-15981msec
==============================
root@pve:~# fio --name=randwrite_ssd --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --runtime=15 --group_reporting --iodepth=32 --directory=/rpool/data/fiotest
randwrite_ssd: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
randwrite_ssd: Laying out IO file (1 file / 1024MiB)
randwrite_ssd: Laying out IO file (1 file / 1024MiB)
randwrite_ssd: Laying out IO file (1 file / 1024MiB)
randwrite_ssd: Laying out IO file (1 file / 1024MiB)
Jobs: 4 (f=4): [w(4)][12.3%][eta 01m:54s]
randwrite_ssd: (groupid=0, jobs=4): err= 0: pid=15942: Tue Jun 24 15:16:26 2025
write: IOPS=9251, BW=36.1MiB/s (37.9MB/s)(584MiB/16165msec); 0 zone resets
slat (usec): min=5, max=1657.8k, avg=427.76, stdev=18378.22
clat (usec): min=4, max=1683.2k, avg=13404.34, stdev=101949.72
lat (usec): min=531, max=1683.2k, avg=13832.10, stdev=103565.46
clat percentiles (usec):
| 1.00th=[ 717], 5.00th=[ 840], 10.00th=[ 914],
| 20.00th=[ 1020], 30.00th=[ 1106], 40.00th=[ 1205],
| 50.00th=[ 1319], 60.00th=[ 1450], 70.00th=[ 1745],
| 80.00th=[ 2606], 90.00th=[ 4686], 95.00th=[ 10683],
| 99.00th=[ 484443], 99.50th=[ 876610], 99.90th=[1551893],
| 99.95th=[1652556], 99.99th=[1686111]
bw ( KiB/s): min= 1800, max=189069, per=100.00%, avg=62067.11, stdev=12682.54, samples=76
iops : min= 450, max=47267, avg=15516.63, stdev=3170.64, samples=76
lat (usec) : 10=0.01%, 750=1.58%, 1000=16.30%
lat (msec) : 2=56.33%, 4=13.33%, 10=7.19%, 20=1.92%, 50=1.71%
lat (msec) : 100=0.24%, 250=0.08%, 500=0.33%, 750=0.41%, 1000=0.17%
lat (msec) : 2000=0.41%
cpu : usr=0.60%, sys=6.82%, ctx=23038, majf=0, minf=52
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,149558,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=36.1MiB/s (37.9MB/s), 36.1MiB/s-36.1MiB/s (37.9MB/s-37.9MB/s), io=584MiB (613MB), run=16165-16165msecElőre is hálásan köszönöm a segítséget!
- 1459 megtekintés
Hozzászólások
Hello !
Hát elég múzeumi darab, sok sikert hozzá.
- Szerintem első körben kéne egy ext4 tesztet futtatni a gépen, abból kiderülne, hogy csak a zfs lassú ennyire, vagy maga a vas. ( Érzésem szerint leginkább az utóbbi, de ennél tényleg többet kéne tudnia, ezért lehet, hogy nincs igazam)
- RAID kontroller tud HBA módot ? Ha tud, érdemes lenne visszakapcsolni és úgy tesztelni (write cache nélkül).
UI:
amúgy nem tudom mit akarsz futtatni a proxmox alatt, de gondolom tisztában vagy azzal, hogy ezen a config-on maga a zfs 10-11 GB ram-ot fog foglalni a 32-ből..
UI2:
ha zfs, akkor ilyen őskövület diszkek mellé kéne még egy normális ssd, amire a local-zfs-hdd pool ZIL-t és L2ARC cache-t kéne tenni.
- A hozzászóláshoz be kell jelentkezni
Szia! A kontroller nem tud HBA módot, azért lett kikapcsolva. Három VM menne csak alatta. Ez a szerver amúgy 2db 3,5"-os HDD-t fogad, egy PICe kártyára (csak hordozó + tápellátás a buszról) került fel két SATA SSD, és direktben az alaplapi SATA portokra mennek. Tudom hogy ez egy öszvér megoldás, de a helyzet az hogy most nagyon low budget megoldást kell szállítani, tegnapra... Ígérték hogy lesz normális vas, addig tűzoltás van.
- A hozzászóláshoz be kell jelentkezni
Nincs is ezzel gond.
Kis pénz, kis foci.
Fedora 42, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
milyen HBA? ha LSI, akkor van crossflash megoldas...
- A hozzászóláshoz be kell jelentkezni
Mit ir ki? zfs get recordsize zfs get sync
Ami nem kerek, hogy ugyanazt méred hdd és ssd esetén is, ezek nem egy pool-ban vannak ?
Ui: Ja , most látom hogy nem.
Egy teszt a tiédnél régebbi szerveren:
bs=4k blokk mérettel tesztelve. A zfs 16 K blokkméretü, a SYNC standard módban van:
root # fio --name=randwrite_ssd --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --runtime=15 --group_reporting --iodepth=32 |grep WRITE
WRITE: bw=212MiB/s (223MB/s), 212MiB/s-212MiB/s (223MB/s-223MB/s), io=3186MiB (3340MB), run=15001-15001msec
bs=16 K blokk mérettel tesztelve, persze jobb:(sokkal), értelemszerűen 4 x , mert a 4k bs esetén is 16 K -t kell írnia.
fio --name=randwrite_ssd --ioengine=libaio --rw=randwrite --bs=16k --numjobs=4 --size=1G --runtime=15 --group_reporting --iodepth=32 |grep WRITE
WRITE: bw=848MiB/s (890MB/s), 848MiB/s-848MiB/s (890MB/s-890MB/s), io=4096MiB (4295MB), run=4828-4828msec
Ha egy nagy recordsize zfs pool-on , pl 128 K blokkméreten akarsz (mintha ez lenne a default), 4k bs randomwrite-ot , az gyalázat lesz, a legújabb vason is.
ha viszont aszinkron írás helyet SYNC-et kérek akkor ez van, ez már hasonlít a tiédhez :
fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
WRITE: bw=14.5MiB/s (15.2MB/s), 14.5MiB/s-14.5MiB/s (15.2MB/s-15.2MB/s), io=100MiB (105MB), run=6902-6902msec
Ez 2 db. Samsung Pro, ( gagyi sata ssd) , zfs tükörben.
- A hozzászóláshoz be kell jelentkezni
Szia! Itt lesz a kutyus elásva, a blokkméretnél. Tudom hogy "worst case" volt a tesztem 4k-val, de ennyire rosszra nem számítottam. Futtattam még pár tesztet 16kB és 128kB blokkmérettel is, íme az eredmények. Ez még mindig elég gyengének tűnik, ennyit tudna ez az olcsó SSD?
==============================
root@pve:~# zfs get recordsize
NAME PROPERTY VALUE SOURCE
local-zfs-hdd recordsize 128K default
rpool recordsize 128K default
rpool/ROOT recordsize 128K default
rpool/ROOT/pve-1 recordsize 128K default
rpool/data recordsize 128K default
rpool/var-lib-vz recordsize 128K default
==============================
root@pve:~# zfs get sync
NAME PROPERTY VALUE SOURCE
local-zfs-hdd sync standard default
rpool sync standard local
rpool/ROOT sync standard inherited from rpool
rpool/ROOT/pve-1 sync standard inherited from rpool
rpool/data sync standard inherited from rpool
rpool/var-lib-vz sync standard inherited from rpool
==============================
root@pve:~# fio --name=randwrite_hdd --ioengine=libaio --rw=randwrite --bs=16k --numjobs=4 --size=1G --runtime=60 --group_reporting --iodepth=32 --directory=/local-zfs-hdd/fiotest
randwrite_hdd: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
randwrite_hdd: Laying out IO file (1 file / 1024MiB)
Jobs: 3 (f=3): [w(3),_(1)][50.8%][w=52.6MiB/s][w=3365 IOPS][eta 00m:59s]
randwrite_hdd: (groupid=0, jobs=4): err= 0: pid=2463: Wed Jun 25 09:54:21 2025
write: IOPS=2792, BW=43.6MiB/s (45.7MB/s)(2626MiB/60194msec); 0 zone resets
slat (usec): min=5, max=3051.1k, avg=1426.42, stdev=48274.73
clat (usec): min=6, max=3122.6k, avg=44340.42, stdev=271125.11
lat (usec): min=428, max=3122.7k, avg=45766.84, stdev=275540.29
clat percentiles (usec):
| 1.00th=[ 627], 5.00th=[ 725], 10.00th=[ 791],
| 20.00th=[ 881], 30.00th=[ 963], 40.00th=[ 1045],
| 50.00th=[ 1139], 60.00th=[ 1270], 70.00th=[ 1565],
| 80.00th=[ 2966], 90.00th=[ 17171], 95.00th=[ 102237],
| 99.00th=[1920992], 99.50th=[2533360], 99.90th=[2902459],
| 99.95th=[3036677], 99.99th=[3070231]
bw ( KiB/s): min= 1472, max=719510, per=100.00%, avg=91138.22, stdev=38141.32, samples=232
iops : min= 92, max=44969, avg=5696.01, stdev=2383.83, samples=232
lat (usec) : 10=0.01%, 500=0.03%, 750=6.46%, 1000=28.11%
lat (msec) : 2=41.49%, 4=7.79%, 10=4.46%, 20=2.15%, 50=2.55%
lat (msec) : 100=1.93%, 250=2.05%, 500=1.14%, 750=0.41%, 1000=0.10%
lat (msec) : 2000=0.46%, >=2000=0.89%
cpu : usr=0.19%, sys=1.99%, ctx=17687, majf=5, minf=55
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,168073,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=43.6MiB/s (45.7MB/s), 43.6MiB/s-43.6MiB/s (45.7MB/s-45.7MB/s), io=2626MiB (2754MB), run=60194-60194msec
==============================
root@pve:~# fio --name=randwrite_hdd --ioengine=libaio --rw=randwrite --bs=128k --numjobs=4 --size=1G --runtime=60 --group_reporting --iodepth=32 --directory=/local-zfs-hdd/fiotest
randwrite_hdd: (g=0): rw=randwrite, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
Jobs: 2 (f=2): [w(2),_(2)][85.4%][eta 00m:06s]
randwrite_hdd: (groupid=0, jobs=4): err= 0: pid=3313: Wed Jun 25 09:58:43 2025
write: IOPS=958, BW=120MiB/s (126MB/s)(4096MiB/34201msec); 0 zone resets
slat (usec): min=18, max=10873k, avg=3284.44, stdev=165230.84
clat (usec): min=2, max=10877k, avg=101912.41, stdev=914772.90
lat (usec): min=23, max=10877k, avg=105196.86, stdev=929232.91
clat percentiles (usec):
| 1.00th=[ 783], 5.00th=[ 824], 10.00th=[ 873],
| 20.00th=[ 1123], 30.00th=[ 1565], 40.00th=[ 1729],
| 50.00th=[ 2507], 60.00th=[ 3261], 70.00th=[ 3687],
| 80.00th=[ 4359], 90.00th=[ 5080], 95.00th=[ 5735],
| 99.00th=[ 5737808], 99.50th=[ 9865004], 99.90th=[10938745],
| 99.95th=[10938745], 99.99th=[10938745]
bw ( MiB/s): min= 1276, max= 3218, per=100.00%, avg=2343.57, stdev=230.14, samples=13
iops : min=10210, max=25749, avg=18748.17, stdev=1841.15, samples=13
lat (usec) : 4=0.01%, 50=0.02%, 100=0.02%, 250=0.06%, 500=0.09%
lat (usec) : 750=0.07%, 1000=13.97%
lat (msec) : 2=29.24%, 4=32.10%, 10=22.36%, 20=0.24%, 50=0.09%
lat (msec) : 100=0.40%, 250=0.09%, >=2000=1.23%
cpu : usr=0.25%, sys=0.69%, ctx=3684, majf=0, minf=55
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.2%, 32=99.6%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,32768,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=120MiB/s (126MB/s), 120MiB/s-120MiB/s (126MB/s-126MB/s), io=4096MiB (4295MB), run=34201-34201msec
==============================
root@pve:~# fio --name=randwrite_ssd --ioengine=libaio --rw=randwrite --bs=16k --numjobs=4 --size=1G --runtime=60 --group_reporting --iodepth=32 --directory=/rpool/data/fiotest
randwrite_ssd: (g=0): rw=randwrite, bs=(R) 16.0KiB-16.0KiB, (W) 16.0KiB-16.0KiB, (T) 16.0KiB-16.0KiB, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
Jobs: 4 (f=4): [w(4)][45.2%][eta 01m:14s]
randwrite_ssd: (groupid=0, jobs=4): err= 0: pid=3642: Wed Jun 25 10:00:58 2025
write: IOPS=2281, BW=35.6MiB/s (37.4MB/s)(2168MiB/60806msec); 0 zone resets
slat (usec): min=6, max=3632.3k, avg=1748.78, stdev=69315.00
clat (usec): min=5, max=3653.0k, avg=54351.49, stdev=383351.70
lat (usec): min=540, max=3653.0k, avg=56100.27, stdev=389399.46
clat percentiles (usec):
| 1.00th=[ 775], 5.00th=[ 898], 10.00th=[ 971],
| 20.00th=[ 1074], 30.00th=[ 1156], 40.00th=[ 1237],
| 50.00th=[ 1369], 60.00th=[ 1532], 70.00th=[ 1876],
| 80.00th=[ 2868], 90.00th=[ 5997], 95.00th=[ 16057],
| 99.00th=[2768241], 99.50th=[3305112], 99.90th=[3539993],
| 99.95th=[3640656], 99.99th=[3640656]
bw ( KiB/s): min= 5440, max=688686, per=100.00%, avg=169992.12, stdev=42503.96, samples=104
iops : min= 340, max=43042, avg=10624.00, stdev=2656.52, samples=104
lat (usec) : 10=0.01%, 20=0.01%, 750=0.67%, 1000=11.70%
lat (msec) : 2=59.33%, 4=14.02%, 10=7.37%, 20=2.44%, 50=1.77%
lat (msec) : 100=0.65%, 250=0.27%, 2000=0.09%, >=2000=1.70%
cpu : usr=0.17%, sys=1.84%, ctx=20232, majf=0, minf=47
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,138729,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=35.6MiB/s (37.4MB/s), 35.6MiB/s-35.6MiB/s (37.4MB/s-37.4MB/s), io=2168MiB (2273MB), run=60806-60806msec
==============================
root@pve:~# fio --name=randwrite_ssd --ioengine=libaio --rw=randwrite --bs=128k --numjobs=4 --size=1G --runtime=60 --group_reporting --iodepth=32 --directory=/rpool/data/fiotest
randwrite_ssd: (g=0): rw=randwrite, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=32
...
fio-3.33
Starting 4 processes
Jobs: 2 (f=2): [_(2),w(2)][80.0%][eta 00m:07s]
randwrite_ssd: (groupid=0, jobs=4): err= 0: pid=3900: Wed Jun 25 10:01:56 2025
write: IOPS=1178, BW=147MiB/s (154MB/s)(4096MiB/27810msec); 0 zone resets
slat (usec): min=18, max=8244.3k, avg=2872.63, stdev=136816.85
clat (usec): min=2, max=8247.1k, avg=89371.12, stdev=758204.55
lat (usec): min=24, max=8247.1k, avg=92243.74, stdev=770193.52
clat percentiles (usec):
| 1.00th=[ 791], 5.00th=[ 832], 10.00th=[ 898],
| 20.00th=[ 1549], 30.00th=[ 1663], 40.00th=[ 2147],
| 50.00th=[ 2573], 60.00th=[ 3195], 70.00th=[ 4015],
| 80.00th=[ 4621], 90.00th=[ 5276], 95.00th=[ 5997],
| 99.00th=[5200937], 99.50th=[8086619], 99.90th=[8220836],
| 99.95th=[8220836], 99.99th=[8220836]
bw ( MiB/s): min= 274, max= 3164, per=100.00%, avg=1631.75, stdev=295.78, samples=18
iops : min= 2198, max=25312, avg=13053.30, stdev=2366.36, samples=18
lat (usec) : 4=0.01%, 50=0.02%, 100=0.02%, 250=0.04%, 500=0.05%
lat (usec) : 750=0.04%, 1000=12.78%
lat (msec) : 2=23.78%, 4=33.28%, 10=27.71%, 20=0.23%, 50=0.21%
lat (msec) : 100=0.09%, 250=0.41%, >=2000=1.32%
cpu : usr=0.26%, sys=0.81%, ctx=4895, majf=0, minf=50
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.2%, 32=99.6%, >=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.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,32768,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=147MiB/s (154MB/s), 147MiB/s-147MiB/s (154MB/s-154MB/s), io=4096MiB (4295MB), run=27810-27810msec
==============================- A hozzászóláshoz be kell jelentkezni
Ezek az értékek még jobbak is, mint amire számítottam a nyitó poszt elejének elolvasása után. Egy normál SATA HDD nagyjából 150 IOPS-t tud. Amit itt kaptál ereménynak 7 ezer IOPS-t, azt a ZFS tudja, rövid ideig (merthogy a ZIL-nek ki kell íródni ténylegesen a lemezre, így ez az IOPS sokáig nem tartható, mert beköszön a HDD fizikai korlátja).
Az SSD-s érték is nagyjából a valóság (bár ezt a 10 ezer kürüli értéket ez hosszabban tudja tartani, mint a 7 ezret a HDD-vel), mert tapasztalatom szerint ezek a Red NAS SSD-k messze nem tudják a gyártó által ígért maximum 80 ezer írási IOPS-t akkor sem, ha ténylegesen 4k-s blokkakkal dolgozik a rendszer minden rétege (mondjuk 10 ezernél lehet többet tudnak ideális esetben).
Ezen felül csatlakozom az előttem szólóhoz, FIO tesztnél muszáj a pool recordsize-t vigyelembe venni az írási blokkméretnél (vagy fordítva: beállítani), mert egyébként nagyságrendekkel több adatot mozgat a ZFS egy IO-ra, mint a blokkméreted, így nem lesz túl objektív a mérés sem. A default recordsize 128k Proxmox esetén is, annyi az extra, hogy ha a Proxmox ír valamit ZFS-re, akkor a storage oldalon megadott recordsize-zal hozza létre a dataset-et hozzá, ami 16k a PVE 8-tól kezdődően (előtte 8k volt).
Mi Kingston DC600M vagy Samsung PMxxx SATA SSD-ket használunk oda, ahová olcsó, de elfogadható SSD-s megoldás kell. Ezek valamivel jobban teljesítenek, mert mindkettő mix-use és PLP-s. De a csoda random írási sebesség csak a PLP-s NVMe mix-use SSD meghajtókkal jön el. Egyébként a Red NAS SSD-k nem PLP-sek, így azok sem tudják igazán soká (pláne folyamatosan) fenntartani az általuk tudott legmagasabb írási IOPS-t. Nem is erre vannak mondjuk, így ez nem hiba.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a részletes információkat. Ez egy budget masina, az olcsóbbnál is olcsóbb megoldás kell... Az Interbolt-on van most HPE firmware-es Samsung PM883 SSD (MZ7LH240HAHQ-000H3) - igaz csak 240GB, ez megfelelhet a célra? Három VM futna rajta a tervek szerint.
- A hozzászóláshoz be kell jelentkezni
Nekünk vannak ugyan ilyen szintű budget ügyfeleink, ahol Dell T30-T40 gépben (ami ugye egy sima desktop, Xeon procival) van 2x SSD és 2x HDD ugyan így (ez már a feljavított verziójuk, eredetileg 2x HDD volt csak ezekben). Alapjában véve (attól eltekintve, hogy nem WD Red az SSD, hanem a fenti írt másik kettő valamelyike) elműködik rajtuk 2-3 VM elfogadhatóan (ha nem túl nagy terhelésű az a 2-3 VM). Szerintem ha egy 240-es Samsung PM-et teszel helyette, nem fog mellbe vágni a sebesség különbség, szerintem nem éri meg kifizetni.
A sebesség az ilyen kis SSD-k esetében egyébként pont a kicsiségüktől is függ, így mi 480 GB-nál kisebbet nem használunk ilyen olcsó esetekben sem (általában ott szokott már annyi NAND chip lenni, ami az SSD vezérlő minden csatornáját leköti, így a vezérlő teljes sebességgel tud dolgozni, a 120-240 GB-osak túl kicsik, így lassabbak).
Én annyit csinálnék, hogy 16k blokkmérettel felvett Proxmox storage-ra feltenném a VM-eket és előben megnézném. Gondolom nem egy fullos fizetős Oracle 21 vagy licencelt SQL Server 2019 fog rajta futni jól megterhelve, hanem 1-2 Windows vagy Linux szerver kicsi terheléssel úgy CPU-ban mint IO-ban.
Esetleg ha belefér a költségvetésbe, én memóriát tennék még bele, hogy a ZFS-nek nagyobb ARC jusson (mondjuk 8 vagy 16 GB és ne csak 2 vagy 4 GB), és akkor teljesen használható lesz. Az írás oldal nem olyan jelentős a válóságban, ha nem komoly DB szerver fut rajta, csak sima átlag Windows/Linux. Meg nyugodtan bekapcsolhatod a VM-eken a writeback cache-t, az ZFS megoldja az ebből eredő kockázatot.
- A hozzászóláshoz be kell jelentkezni
Itt is kb. ez a feladat, kisebb terhelésű VM-ek. Van T30-am is ha úgy alakulna, de ez a HP ide jobb lenne (kevés hely van, befér a rack-be).
"Én annyit csinálnék, hogy 16k blokkmérettel felvett Proxmox storage-ra feltenném a VM-eket és előben megnézném."
Jelenleg a recordsize a zvol-on 128k. Ez így jó? A 16k-t hol állítsam be? Kezdő ZFS-es vagyok, nézzétek el nekem a kérdéseim. :))
- A hozzászóláshoz be kell jelentkezni
zfs create -o volblocksize=16K...
- A hozzászóláshoz be kell jelentkezni
Proxmox esetén a Datacenter/Storage alatt amikor felveszed a ZFS pool-t tárolónak, ott meg tudod adni milyen volblocksize (merthogy zvol-nál nem a recordsize játszik) legyen használatban. Aztán azzal fogja létrehozni a zvol-okat VM-nek. Ha változtatsz rajta, akkor az természetesen visszamenőleg nem lesz érvényes, a már létező VM/CT tárolása nem változik, de az újonnan létrehozottak már az új beállítással fognak létrejönni.
Ha nem nyúltál hozzá telepítés után és a local-zfs tároló (rpool/data) van VM/CT részére, akkor az default 16k volblocksize értékkel fut.
Ha maguk a zvol-ok amik a VM-ek alatt vannak nagyobb értékkel jöttek létre (ami csak kézi elállítás után lehet, a default 16k), akkor azt csak úgy tudod "kijavítani", hogy csinálsz egy új dataset-et a pool-on (zfs create rpool/ujdataset) és azt hozzáadod a Proxmox-hoz a Datacenter/Storage alatt, 16k volblocksize értékkel, és a VM-nél Move Disk az így létrehozott Storage-re. Ha az összes VM összes diszket átmozgattad így, akkor vagy eldobod az addigi, nagyobb blokkmérettel felvett Storage-t a Proxmox-ból, vagy átállítod 16k-ra és vissza move-olod a diszkeket. De nem kell oda-vissza mozgatni, mert az egy pool-on belül gyakorlatilag annyi, melyik "könytárban" vannak a lemezképek (zvol-ok).
- A hozzászóláshoz be kell jelentkezni
Köszönöm útmutatásod. A block size az alapértelmezett 16k-n van, készítek pár VM-et és kiderül hogy' viselkedik.
- A hozzászóláshoz be kell jelentkezni
ZFS azon kívül hogy Proxmox tudja, van bármi más ok amiért használni szeretnéd?
Ha nincs, akkor tegyél a gépbe valamilyen HW RAID kártyát, és ott tedd a lemezeket neked tetsző RAID-ba.
Vagy ha maradsz a mostani confignál, akkor simán Linux softraid (proxmox telepítő nem tudja!, de sima debian MDRAID install, majd arra kézzel felrak proxmox)
Ezen a gépen, és látva mire használnád, teljesen overkill és szükségtelen ZFS.
MDRAID + proxmox LVM storage mindent tud amit ZFS-el tudnál.
- A hozzászóláshoz be kell jelentkezni
A ZFS egyetlen hátránya, hogy kell neki valamennyi memória (a többi egyszerűbb FS-hez képest). Az összes többi előnye ezt bőven kompenzálja (szerintem), és egy ilyen HW-en nem lesz érdemben lassabb, mintha kézzel mapetkodna mdraid-del meg rajta LVM-mel. Én aránylag sokat kísérleteztem ezzel, mikor előjöttek ilyen ügyféligények a hét szűk esztendők idején, hogy egy megmaradt Sharp zsebszámológépre tegyünk VM-be két-három szolgáltatást, mert nincs pénz komolyabb hardverre. Vagy elhajtjuk, vagy kitaláltunk valamit. Mi a kitalálunk valamit mellett vagyunk, kevés ügyfelet hajtunk el. Ez nem az a környék, ahol dúskálnánk a tőkeerős és IT-ra költeni akaró cégekből (sajna). Így legalább lehet normális munkadíjat kérni, mert marad rá (ha nem maradna, akkor elhajtanánk...).
- A hozzászóláshoz be kell jelentkezni
Három dolog miatt szeretném itt a ZFS-t, ha lehet:
1: az adatintegritás beépített módszerrel történő ellenőrzése (scrub)
2: fájlrendszer szintű snapshot-ok kezelése (tudom, a qcow2 is tud snapshot-ot)
3: nem kellene függeni a RAID vezérlőtől: nincs hozzá driver/tool, S.M.A.R.T.-ot trükközve elkérni, stb.
- A hozzászóláshoz be kell jelentkezni
Éles használatú Proxmox esetén nem szabad taknyolni, mert nagyon sok megoldástól elesik az ember.
A ZFS-nél a Proxmox képes
- Snapshtotolni a VM-eket natív ZFS snapshottal
- Node-ok között VM-eket (diskeket) mozgatni (zfs send-recv) ha egységes a storage poolok elnevezése
Ráadásul ZFS-sel kicsit egyszerűbb a backupolás is a periodikus snapshotolással (általában ilyen low budget ügyfelenél nem szokott lehetőség lenni az offsite backupra vagy egyáltalán dedikált backup szerverre). Igen, ezek a megoldások eszetlenül messze vannak bármitől, amit kicsit is optimálisnak mondana az ember, és hosszú a kockázatok listája. De ha abból kell főzni, amit hozzánk vágnak, ez egy tök jó megoldás is tud lenni - a hibái ellenére is.
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Elengedtem a régi szerverecskét, hétfőn érkezik az "új" (használt) helyette. A főbb paraméterei:
- 2x Intel Xeon Gold 6262 CPU
- 256GB DDR4 REG ECC RAM
- DELL HBA330 SAS HBA
- 2x Samsung PM883 Enterprise SATA SSD
- 4x U.2 NVMe Gen3 SK Hynix PE6011HFS1T9GDUFEH-A430A SSD
A terv: a két darab SATA SSD lesz az alaprendszeré, plusz mehet oda a pár szükséges telepítő ISO, stb. Sima szoftveres tükörben. A 4db NVMe SSD pedig ZRAID-1 kötetbe lenne szervezve, 16k alapértelmezett blokkmérettel és 12-es alapértelmezett ashift értékkel. Ehhez az összeállításhoz megfelelőek ezek a beállítások? A ZFS egyelőre szürke terület nekem, ezért kérek tőletek segítséget, amit előre is köszönök!
- A hozzászóláshoz be kell jelentkezni
Intel Xeon Gold 6262 CPU szerintem tudja a persistent memoriát, nem olyan drága mert már nem gyártják, cégeknek ezért már nem kell, lehet használni mintha lemez lenne, (direct mode) egy nagyságrendel gyorsabb bármilyen ssd-nél, mivel ez is optane. Nem használtam , de tesztek jókat mondtak róla.
https://www.ebay.com/itm/297399481592?_skw=persistent+memory+modul
- A hozzászóláshoz be kell jelentkezni
Szia! A hardver konfiguráció már végleges, így egyben érkezik a DELL masina, ezzel kell dolgozni. A kérdésem arra irányult hogy megfelelő-e az alapértelmezett ashift és block size, vagy javasolnátok eltérőt, és ha igen, miért.
- A hozzászóláshoz be kell jelentkezni
Megfelelő 4K blokk, 12 ashift.
Ha tisztán egy datasetbe csak adatbáziskezelő van akkor lehet 16K blokk , 14 ashift, mert az adatbáziskezelők 16K blokkméretet használnak. De ha már vegyesen használod nem jó, mert a kis fájlokat is 16 K-n tárolod, ami meg lassít.
IOPs: adatbáziskezelők default nem használnak szinkron irást (inkább dupla napló stb) Viszont a proxmox a host oldalon a default beállítása no-cache. Ezért javasoltam, ha valami nagy adatbiztonság kell, vagy nagy iops a PMM-et, mint alternatívát.
DC ssd random sync write 30 MB/sec, optane 300 MB/sec. De ez csak tényleg nagy adatbiztonságú, szinkron adatbáziskezeléshez kell, ami azért nem általános.
Pmm ennél is jobb: (Ezek akkor milliós áron voltak iparnak sem kellet, ma meg azért nem kell iparnak mert nem gyártják) itt ott használtan emberi áron elérhtőek,
Egy régebbi mérés 4k/random szinkrin write 228 MB/sec. De nyilván ez a csúcs, sima webszerverbe nem kell.
https://hup.hu/comment/2401897#comment-2401897
ZFS: zfs-t magas adatintegritásra és fájlrendszer integritásra tervezték, ext4 "csak" magas fájlrendszer integritásra (naplozó) , ez az ára a zfs-nek.
- A hozzászóláshoz be kell jelentkezni
A RaidZ1 egy RAID5 megvalósítás, szóval paritás számolás, alacsony írási IOPS, egyetlen lemez hibatűrés. Ha ez virtualizáció alá megy, én RAID10 felállást javaslok (ZFS-nél ez két mirror VDEV egy pool-ba), hiába több a tárkapacitás bukó. RaidZ1-2-3 hosszútávú, főleg olvasási terhelésű, nagy mennyiségű adattárolásra való (1-2-3 attól függ mennyire nagyok a diszkek és milyen gyorsan szeretném hiba esetén cserélni), nem random RW feladatra.
Az U.2 NVMe meghajtók mire lesznek kötve? Merthogy a HBA330 nem tri-mode vezélő, az csak SAS és SATA meghajtókat tud kezelni.
Egyébként az ashift=12 jó lehet (én nem találtam meg a neten, milyen "szektorméretű" ez a meghajtó, de ha kiderül, hogy 8k nem 4k, akkor ashift=13 kell), és a 16k-s blokkméret a Proxmoxnál a legtöbb feladatra megfelelő lesz.
- A hozzászóláshoz be kell jelentkezni
Ha pár alacsony terhelésű VM lesz rajta (valahol a szálak között ez leírattatott) akkor a RaidZ1 általad említett korlátai nem lesznek probléma (nem nagy terhelésű SQL szerver kerül rá például).
- A hozzászóláshoz be kell jelentkezni
Én szervert mindig hosszabb távra tervezek, mert a legtöbb helyen nem szeretik újra megvenni, jelentős pénzen bővíteni, átalakítani a tervezett élettartamán belül. Emiatt nekem nem az a lényeg, hogy most épp mit fog csinálni, hanem az, hogy az elképzelhető terheléseket az általánosan elvárt 3-5-7 évig ki tudja majd szolgálni. Ahogy a tárkapacitását, meg a CPU teljesítményt, RAM mennyiséget sem az aktuális igényhez méretezem, hanem a várható bővüléshez és az esetleg már ismert szűk keresztmetszethez.
Ezek alapján adok tanácsot is.
Nyilván bármilyen SSD-re épített tömbön el fognak futni normálisan a kis terhelésű VM-ek. De attól még a RaidZ módok nem random R/W I/O-ra vannak kitalálva, így tanácsként nem is mondom senkinek, hogy jó az arra, mert most épp nem kell több.
Egyébként sokszor tapasztalom, hogy ha kerül valahová egy jól működő szerver az addigi régi/lassú/stb. helyett, akkor hirtelen megjelennek az addig nem létező igények plusz feladatokra. Mert látják, hogy nem a szerver létével volt a baj addig sem, hanem a teljesítményével. Amikor meg már jól szolgál pl. felújítás vagy csere után, akkor mehet rá más is, amihez meg több erőforrás kell, mint a régi feladatokhoz kellett.
- A hozzászóláshoz be kell jelentkezni
Dicséretes ez a hozzáállás!
Jelen esetben egy használt DELL R640 masina jön, az SSD-k újak lesznek benne. Fenti kérdésedre válaszolva: tudomásom szerint a gyári backplane + kábelkészlettel csatlakoznak majd az U.2 SSD-k. A HBA meg azért nem RAID vezérlő, hogy szoftveres RAID lehessen a Proxmox telepítés alatt. A szerveren kb. 50-50%-ban Linux és Windows virtuális gépek fognak futni, vegyesen. Semmilyen extra terhelés nem lesz, sem nagyméretű, írásra masszívan igénybe vett adatbázisok. Általános célú VM-ek (AD DC, tűzfal, levelezés, Nextcloud, pár mikroszerviz Docker-ben). Kapacitásban fölé lett tervezve, memória is elég lenne a fele, de a ZFS-nek kell, ezért lett ennyi.
- A hozzászóláshoz be kell jelentkezni
Ha lesz rá időd, egy két alap fio mérést megoszthatsz majd.
- A hozzászóláshoz be kell jelentkezni
Igen, az R640-nél volt olyan opció, hogy a 10x SSF kivitelben lehetett 4 vagy 8 NVMe slot opcionálisan, és az alaplapon ott vannak hozzá a csatlakozók, a backplane meg a plusz kábelek a különbség. Gondolom a beszállító olyan alapgépet ajánlott, amiben legalább a 4x U.2 kiépítés megtalálható. Azért kérdeztem, mert a HBA330 a 13. generációval jött, amiből kézenfekvő az R630, amiben szintén volt opcionálisan 4x NVMe támogatás, de az nagyon ritka és külön kártya kellett még hozzá a backplane támogatáson felül. Nehogy az legyen, hogy a gép nem tudja. De akkor ezek szerint tudja.
Jól tetted, hogy HBA-t kértél, nekem sem barátaim a HW RAID kártyák, jobban szeretem a szoftveres, abszolut hordozható megoldásokat. Egyébként a Dell-nél a 13. generációtól (PERC H730 és fölfelé) már tudják a HW RAID vezérlők, hogy vagy átkapcsolod HBA módba teljesen (Setup-ban, nem kell trükközni), vagy olyan is lehet, hogy pár diszk HW RAID kötet, a maradék meg Non-RAID módban direktben az OS-hez jut (akár SMART adatokat is le lehet kérdezni, szóval valódi kontrollt kap az OS ezek felett, nem virtuális trükközést). Nekem ez már jól jött VMware költöztetéskor, ami HW RAID-en volt, és Proxmox lett helyette, ami ZFS-t használt. A Proxmox-ban lehetett így mount-olni a VMFS6-ot és nagyon egyszerű volt a VMDK import extra hardver vagy másik szerver nélkül.
A ZFS memória igénye ezen a gépen nem lesz túl magas (persze meg lehet vele etetni sokat, csak minek). RAID5-ben a 4 db 1.92 TB-os SSD szűk 5.4 TB hasznos, annak elég 2 GB alap + 6 GB ARC memória. Összesen 8 GB zfs_arc_max értékkel már teljesen jó lesz. Persze adhatsz neki többet, a Windows-ok meghálálják. De arra figyelj, hogy a default a rendelkezésre álló memória fele! Szóval javaslom mindenképp alacsonyabbra venni, ha nem is 8 GB-ra, mondjuk 32-re. Telepítéskor ezt meg tudod adni, ha a rendszert is ZFS mirror-ra teszed, ott van arc_max beállítás. Valamint mindenképp UEFI-vel telepítsd a Proxmox-ot, ne Legacy módban.
- A hozzászóláshoz be kell jelentkezni
Köszönöm tanácsaid! Írok egy PM-et is.
- A hozzászóláshoz be kell jelentkezni
> Amikor meg már jól szolgál pl. felújítás vagy csere után, akkor mehet rá más is, amihez meg több erőforrás kell, mint a régi feladatokhoz kellett.
De ezt a helyi üzemeltető/DevOps feladata visszahajtogatni. Ehhez persze hasznos mérni a jelenlegi rendszer kapacitás kihasználtságát, és lehet mutogatni, hogy nézd, igen gyorsabb lett, de ez ennyit tud, ennyire ki van használva, entül másra nem biztos, hogy alkalmas...
- A hozzászóláshoz be kell jelentkezni