ZFS pool extremne pomaly scrub

[molnart]

Konfiguracia je nasledovna:
6x 12tb HGST SAS diskov v dvoch raidz-1 vdevoch. disky nevykazuju ziadne smart errory. konfiguracia bola vytvorena "naraz", takze nebolo ziadne pridavanie diskov a podobne veci. na ziaciatku som ale musel vymenit jeden disk, lebo bol v podstate DoA.

pool ma nastaveny pravidelny scrubbing raz mesacne, a problem je ze trva kazdym mesiacom coraz dlhsie. momentalne uz bezi 4. den.prvotne rychlosti su cez 800 MB/s, no po dosiahnuti asi 85% to klesne aj pod 5 Mb/s, vid vystup zo zpool iostat

Kód: Vybrať všetko

               capacity     operations     bandwidth 
pool         alloc   free   read  write   read  write
-----------  -----  -----  -----  -----  -----  -----
StoragePool  36.2T  27.9T  1.52K      0   890M      0
StoragePool  36.2T  27.9T  1.68K      0   874M      0
StoragePool  36.2T  27.9T  1.40K     35   864M   672K
StoragePool  36.2T  27.9T  1.32K    133   811M  16.8M
StoragePool  36.2T  27.9T  1.52K      0   883M      0
StoragePool  36.2T  27.9T  1.59K      0   921M      0
StoragePool  36.2T  27.9T  1.71K      0   909M      0
StoragePool  36.2T  27.9T  1.57K      0   870M      0
StoragePool  36.2T  27.9T  1.82K      0   891M      0
StoragePool  36.2T  27.9T    975    208  63.8M  20.0M
StoragePool  36.2T  27.9T   1021      0  19.6M      0
StoragePool  36.2T  27.9T    989      0  25.1M      0
StoragePool  36.2T  27.9T    947      0  22.4M      0
StoragePool  36.2T  27.9T  1.01K      0  22.0M      0
StoragePool  36.2T  27.9T    915      0  19.7M      0
StoragePool  36.2T  27.9T    620      0  17.5M      0
StoragePool  36.2T  27.9T    475      0  16.1M      0
StoragePool  36.2T  27.9T    495      0  16.5M      0
StoragePool  36.2T  27.9T    479      0  14.2M      0
StoragePool  36.2T  27.9T    484      0  13.4M      0
StoragePool  36.2T  27.9T    506      0  14.9M      0
StoragePool  36.2T  27.9T    359      0  15.7M      0
StoragePool  36.2T  27.9T    468    310  21.3M  35.7M
StoragePool  36.2T  27.9T    989      0  18.9M      0
StoragePool  36.2T  27.9T    975      0  17.9M      0
StoragePool  36.2T  27.9T   1003      0  18.7M      0
StoragePool  36.2T  27.9T    925      0  18.0M      0
StoragePool  36.2T  27.9T    695      0  17.6M      0

StoragePool  36.2T  27.9T  1.27K      0  6.67M      0
StoragePool  36.2T  27.9T    863      0  4.58M      0
StoragePool  36.2T  27.9T    647      0  4.05M      0
StoragePool  36.2T  27.9T    549      0  4.01M      0
StoragePool  36.2T  27.9T    467      0  2.40M      0
StoragePool  36.2T  27.9T    355      0  3.71M      0
StoragePool  36.2T  27.9T    813    273  4.70M  34.5M
StoragePool  36.2T  27.9T  1.91K      0  9.86M      0
StoragePool  36.2T  27.9T  1.27K      0  6.67M      0
StoragePool  36.2T  27.9T    863      0  4.58M      0
StoragePool  36.2T  27.9T    647      0  4.05M      0
StoragePool  36.2T  27.9T    549      0  4.01M      0
StoragePool  36.2T  27.9T    467      0  2.40M      0
StoragePool  36.2T  27.9T    355      0  3.71M      0
StoragePool  36.2T  27.9T    813    273  4.70M  34.5M
StoragePool  36.2T  27.9T  1.91K      0  9.86M      0

co mi ale pride divne, je ze tie dva vdevy su v podstate v RAID-0 konfiguracii, z nejakeho dovodu je ich naplnenie ale hodne nerovnomerne, co si nedokazem nijako vysvetlit.

Kód: Vybrať všetko

molnart@omv6:~$ zpool iostat -v StoragePool
                                            capacity     operations     bandwidth
pool                                      alloc   free   read  write   read  write
----------------------------------------  -----  -----  -----  -----  -----  -----
StoragePool                               37.3T  26.9T    182     63  24.2M  5.26M
  raidz1-0                                16.2T  15.9T     64     25  10.7M  1.82M
    a755e11b-566a-4e0d-9e1b-ad0fe75c569b      -      -     22      7  3.59M   621K
    7038290b-70d1-43c5-9116-052cc493b97f      -      -     20      7  3.58M   621K
    678a9f0c-0786-4616-90f5-6852ee56d286      -      -     21     11  3.58M   621K
  raidz1-1                                21.1T  11.0T    117     37  13.5M  3.44M
    93e98116-7a8c-489d-89d9-d5a2deb600d4      -      -     39     12  4.50M  1.15M
    c056dab7-7c01-43b6-a920-5356b76a64cc      -      -     38     12  4.50M  1.15M
    ce6b997b-2d4f-4e88-bf78-759895aae5a0      -      -     39     12  4.49M  1.15M
----------------------------------------  -----  -----  -----  -----  -----  -----

ked sa pozriem na utilizaciu diskov, tak cela zataz je na diskoch v raidz1-1 (vsetky 3 disky maju zataz okolo 85%, kym ostatne chilluju pod 10%).
mate nejaky napad co s tym? mozno jeden z diskov je predsalen vadnych, ale ako zistim ktory z tych troch?

[zoom]

Divnô. Mam tiez 6 diskov, akurat pouzivam RAID-Z2. Podla command-line mas ocividne OpenMediaVault, ktory je zalozeny na Linuxe, cize cca ako moj TrueNAS Scale. Mam zapratnych necelych 12TB a scrubbing vyzera takto (vidim, ze StoragePool je univerzalny nazov ):

Kód: Vybrať všetko

root@nas[~]# zpool status
  pool: StoragePool
 state: ONLINE
  scan: scrub repaired 0B in 03:54:27 with 0 errors on Sun Nov 10 03:54:29 2024

Takze ak mas zaplnenych nieco cez 8TB, tak to musis mat hotove este skor. Niekde je celkom urcite chyba. Celkom zaujimavo mas urobene to pole... akoby RAID0+1 teda? Ze mas Pool, ktory lezi na Stripe a v kazdom Stripe mas 3 disky v RAID-Z1, takze vlastne disk a 2 kopie? Kvoli vacsej vyuzitelnej kapacite by som mozno siel cisto do RAID-Z2, alebo pri rovnakej kapacite a asi mensej problemovosti do RAID-Z3. Co sa tyka nerovnomerneho ukladania dat - si si isty, ze mas RAID0 navrchu? Nie je to len VDEV, ktory vyuziva dva RAID1 (RAID-Z1), a teda je to akoby mal 2 samostatne disky a tam si uklada, ako uzna za vhodne? Ale to potom asi nesedi matematika existujucej kapacity... hm.

Predpokladam, ze mas najnovsi OMV, tym padom aj ich najnovsi OpenZFS. Mas upgradnute pole na najnovsie ZFS flagy? Neviem, ako to ma OMV poriesene, ale ked upgradujes TrueNAS a ma novsie ZFS, tak to treba vyslovene manualne upgradnut (prestane byt kompatibilne so starsou verziou). Moze to byt zobrazene niekde v GUI, alebo aj ten "zpool status" prikaz by vypisal, ze je moznost upgradovat pole. Prikaz "zfs version" ti vypise aku verziu zfs balicka? Aj by som porovnal s mojou, ale TrueNAS ukazuje zfs-2.2.99-1, co bude nejaky ich fork, kedze posledna ofiko GitHubova je 2.2.7.

Tie disky nie su nahodou so SMR zapisom? Kolko RAM mas v NAS? Taky rule of thumb pre ZFS je 1GB RAM na 1TB diskov, tak pri tej kapacite hadam 64GB RAM. Ale popravde neviem, ci to moze sposobovat tento problem.

A este jeden napad: Kedze mas SAS disky, tak to asi ide cez pridavnu kartu. Tam nemoze byt nieco? Nejaky cinsky LSI firmware a podobne? To je presne take nevysvetlitelne cosi, co by som pripisal takym suflikantom.

[molnart]

dost som skumal ako nastavit raid pool a isiel som touto variantou lebo dva striped vdevy by mi mali dat dvojnasobny iops a vseobecne som narazal na nazor ze by sa nemali pouzivat "siroke vdevy". povodne som pool vytvaral v TrueNAS Scale, potom som ho prehodil do OMV lebo chcem popritom na inych diskoch pouzivat aj ine filesystemy. verziu zfs mam 2.2.6. neviem co mas za verzoiu 2.2.99 lebo taka podla githubu neexistuje https://github.com/openzfs/zfs/releases, 2.2.7 vysla dnes rano.

disky SMR nie su, pochybujem ze by vobec existoval SAS disky z 2019 ktore by boli SMR. ram mam 48 Giga, ale ARC cache sa sprava tiez divne. mam nastavenych 32 Giga, ale vyuzitych je len 22.8...

LSI karta by to teoreticky mohla robit, ale tu kartu mam uz hodne davno este predtym ako som mal ZFS a nikdy nevykazoval ziadne problemy. a hlavne si myslim ze keby to bolo kartou, tak spomalenie by nenastalo vzdy na rovnakom mieste ale bolo by pomale cely cas.

[zoom]

Tak asi len zacat uplne od zaciatku - logmi? Podla mna mas celkom dobry stav, ze na zaciatku ide scrubbing rychlo a az neskor pomaly. Robil by som logy vsetkeho z obidvoch situacii. Uplny zaklad je vytazenie CPU, volna RAM, aktualne procesy v systeme (top, htop, iotop), potom samozrejme vytazenie diskov a ak existuje nieco na vytiahnutie aktualneho stavu z LSI karty, tak aj to (vytazenie CPU, vytazenie cache alebo co). Cim podrobnejsie, tym lepsie. Kludne aj viac utilit na rovnaku vec, lebo jedna moze zobrazit tak, druha inak. Hocijake obskurne logy, ak sa daju vytiahnut... zaplnenie cache na diskoch, queue na diskoch, nejake ZFS statistiky, reportovanu teplotu CPU na tom LSI HBA (ak nebude dostupne vytazenie, moze indikovat, ze cosi sroti), atd.

Pozbierat (doinstalovat) kludne nejake externe utility, len jednoducho potahat co najviac dat. Po 30-60-90 minutach, ked to ide rychlo, potom 3 data pointy, ked to ide pomaly. Hladat v tych logoch nejaky rozdiel. Je to troubleshooting zadarmo. Mozes tiez skusit disky po jednom vytiahnut a v tvojom PC ich prebehnut utilitou od vyrobcu (extended scan), ci je vsetko OK.

Inak... teraz pozeram, ze existuje aj novsi firmware pre HGST SAS 12TB disk tu. To som nasiel na Googli a neviem, aky mas, ale mozes skusit pozriet a pripadne updatnut disky s firmwarom. Tiez to ma sancu na uspech.

Este mi napadlo:

• Ked ten scrubbing ide tak extra pomaly, tak vtedy vies prenasat rychlo data z/na diskove pole? Akoze len scrubbing ide pomaly, alebo je spomaleny komplet cely system ci diskove I/O?
• Nahodou ten scrubbing si nerobil aj na TrueNAS Scale? Ze ak to tam bolo v poriadku, skor by som hladal vinu v OMV.

[molnart]

kedze scrubbing trva coraz dlhsie (tak cca. + 2 dni kazdy mesiac), tak pod TrueNAS sa to neprejavovalo, lebo vtedy boli este disky relativne prazdne.

k tym logom, mas nejake tipy co konkretne logovat a akymi utilitami ? lebo iostat mi sice ukazal ktore disky su zatazane, ale je to cely vdev a nezistim z toho ktory disk konkretne https://imgur.com/a/iostat-zfs-R5CQx6A

napadlo mi ze budem navtrdo vytahovat disky po jednom nahradit inym, urobit resilver a sledovat rychlosti a pride mi to ako take bruteforce riesenie

edit: no ale ze by to bolo predsalen firmwareom? moje disky su HUH721212AL5204 a maju verziu NE01 (co mi pride ze bude netapp firmware). tuto sa pise o nejakom critical errory ktory dopocuruje nainstalovat verziu NE02 https://lenovonetapp.com/technical-serv ... su554.html ktora ale vysla az tento rok, na disky ktore maju 5 rokov.

na stranke HP je firmware pre rovnaky disk s verziou C9G0, co teda asi bude HP verzia. https://support.hpe.com/connect/s/softw ... leaseNotes

[molnart]

zatial najblizsim conclusionom z ineho fora je, ze problemom je 1M recordsize na datasetoch ktore obsahuju vela drobnych suborov v rozsahu jednotiek kilobytov. a kedze recordsize sa neda spatne zmenit, tak bud data prekopirujem inde a naspat (co pri 8+ TB dat s malymi subormi moze trvat kludne tyzden, co je downtime ktory neviem ci si mozem dovolit) alebo zmenim on the fly a budem dufat ze ako postupne sa stare data premazu (kedze vacsinou ide o zalohy ktore maju nejake retention) tak sa nastane nejake postupne zrychlenie

[zoom]

Tak teoreticky by ta situacia mohla odpovedat - kym boli prazdne disky, bolo to lepsie a postupne, ako sa zaplnaju, sa to spomaluje. Ja mam recordsize defaultnu (128K), ale vo velkej vacsine uchovavam velke subory. Na particii na zalohovanie mam asi 20 tisic suborov roznych velkosti, ale ocividne to nerobi problem.

K tym toolom - neviem, nepoznam nejak zasadne. Ja som Windows clovek, tak len tych par, co som vymenoval + som cital, ze jeden tool niekomu ukazal, ze nic nie je vytazene a druhy ze nejaky proces cakal na nieco, tak preto radsej viac aj prekryvajucich sa.

Ten firmware by som urcite skusil aktualizovat, ak sa to bude dat. Minimalne na tej HP stranke je kopec updatov, posledny z tohto decembra, tak sa celkom staraju. Aj ked to nepomoze, pre dobry pocit. Idem si vlastne aj ja pozriet, ci nieco nevyslo na moje disky.

No a ked mas len 8TB dat, nie je to jednoduchsie odohrat na 2 disky (akoze 2x rovnake data do zalohy) a len vyrobit novy Pool s inymi parametrami? Nejako sa mi nezda, ze by to muselo tyzden odohravat (citat) z toho pola. Kopirovanie nazad by uz malo byt rychlejsie... iba ze by to nebolo tym a budes to tam naozaj aj dlho nahravat. Ale inak nic nemam ine, takze presne taka odpoved... mohol by si, mohlo by, vyskusaj, atd.

[Chris]

tak zaprve si skus skontrolovat teplotu diskov, ked zacne citat a zapisovat (scrub) tak sa zacnu hriat a zacne throttling.

1MB je fajn, zalezi ake mas data a ake zapisuju, ale pridaj si nejake 2x SSD do mirroru pre Special device.

Pripadne skus zvazit aj ZIL na separe 2x nvme mirror pri 12+ 3.5" HDD pooloch.

Takisto neviem ci si uvedomujes, ale ak zarezervujes L2ARC 70% total ram, tak sice budes mat cachovane subory pre READ, ale WRITE si zabil a bud zacne swapovat, alebo ak mas swapines nizky, tak pretlak ram, co sa ti deje, ze alokuje len 22GB ram.

enjoy

[molnart]

tak zaprve si skus skontrolovat teplotu diskov, ked zacne citat a zapisovat (scrub) tak sa zacnu hriat a zacne throttling.

disky maju vsetky okolo 33 stupnov, aj keby jeden vyskocil neviem na 37, tak si nemyslim ze by to nieco extra znamenalo, pri ambietnej teplote 20 stupnov (za zatvorenymi dverami racku, mimo neho tak 15)

ale pridaj si nejake 2x SSD do mirroru pre Special device.

na to nemam aktualne priestor kam dat este dalsie dva disky. teraz ich tam mam 11.

Takisto neviem ci si uvedomujes, ale ak zarezervujes L2ARC 70% total ram, tak sice budes mat cachovane subory pre READ, ale WRITE si zabil a bud zacne swapovat, alebo ak mas swapines nizky, tak pretlak ram, co sa ti deje, ze alokuje len 22GB ram.

tomuto nerozumiem moc. L2ARC som navysil preto lebo som mal zbytocne zvysok RAM nevyuzity, ked okrem ZFS je spotreba ram tak do 4 Giga.
volenho ramu je podla mna stale dost (a swap mam plny aj vzdy a vsade)

htop.png

ako teda mam nastavit cache aby optimalne vytazil ram na citanie aj zapis (celkovo je viac write loadu ako readu, v podstate read sa deje len pri scenaroch ako scrubbing, garbage collection apod.) ked neratam streamovanie nejakeho videa ktory sa deje tak hodinu denne, rychlostou 10-15 mb/s

Tak teoreticky by ta situacia mohla odpovedat - kym boli prazdne disky, bolo to lepsie a postupne, ako sa zaplnaju, sa to spomaluje. Ja mam recordsize defaultnu (128K), ale vo velkej vacsine uchovavam velke subory. Na particii na zalohovanie mam asi 20 tisic suborov roznych velkosti, ale ocividne to nerobi problem.

kym boli disky prazdne tak tie male subory som tam nemal.
tych suborov tam mam odhadom tak 50 milionov, kedze v 6TB datasete je najvacsi subor ktory ma 2 MB a potom jednotky bytov.
teraz som len cez fdupes vymazal necelych milion duplikovanych suborov ktore boli ulozene stylom ze kazdy mesiac nakopirovana zlozka z PC do komplet novej zlozky, takze niektore subory tam boli aj cez 100x.

[zoom]

Pokial su vsetky tie subory nejake zalohy z PC, mozno by som uvazoval o zmene sposobu zalohovania. Nez kopirovat X-krat trilion suborov, tak to cestou pakovat do ZIPu alebo robit image zalohovacim softom (klasika gradfather-father-son, ze velky image, k nemu rozdielove a inkrementalne images).

Pre zaujimavost prikladam moj htop:

swap.png

Swap je 0kB. Na NAS bezi v QEMU Windows VM s alokovanymi 16GB RAM. ARC papka RAM, ale inak sa vsetko zmesti. Mam vsak o dost menej procesov (Tasks: 54, 194 threads).

Nasiel som aj toto. Ocividne ZFS on Linuk uklada rozsirene atributy do suborov, tak hentym by sa to malo zmenit na ukladanie do inodes. Ci to pomoze, alebo ci to TrueNAS/OMV uz ma by default zmenene, to neviem. Ale zrovna v tvojom use case by to mohlo nieco pomoct. Akurat chyba lavky - asi to funguje len pre novo zapisane subory.

Dalsi klasicky hack je vypnutie atime na Poole, ak nepotrebujes (last access time). I ked na TrueNAS je defaultne zapnute aj relatime, ktore modifikuje spravanie atime (naupdatuje ho vzdy, len v urcitych pripadoch). Toto je uz skor take varenie z vody.

[Chris]

Asi sa nechapeme, aké máš write rýchlosti random a sequence?

[molnart]

Pokial su vsetky tie subory nejake zalohy z PC, mozno by som uvazoval o zmene sposobu zalohovania. Nez kopirovat X-krat trilion suborov, tak to cestou pakovat do ZIPu alebo robit image zalohovacim softom (klasika gradfather-father-son, ze velky image, k nemu rozdielove a inkrementalne images).

mne to nemusis hovorit, to nie su moje zalohy ja robievam inkrementalne zalohy cez restic. ked som toto uvidel tak som pochopil preco chcu clenovia rodiny kazde 2 roky na vianoce novy externy disk, ked tych istych 50 Giga dat tam nakopiruju kazdy tyzden a potom maju single point of failure. tak ked som riesil obnovu dat z takto zazalohovaneho a samozrejme pokazeneho disku tak som si to ulozil k sebe a este na jednu offsite lokaliciu, nech to nemusim za 5 rokov opat obnovu dat riesit.

Swap je 0kB.

neviem preco ja mam plny swap. swappiness mam na 60. ked som to davnejsie pozeral tak som niekde nasiel ze linux si takto offloadne veci ktore su v pamati permanentne, tak som to prestal riesit.

Nasiel som aj toto.

to uz mam nastavene celkom davno. tusim nie od novoty a menil som to az neskor.

Dalsi klasicky hack je vypnutie atime na Poole,

s tymto som sa uz hral tiez. atime mam zapnuty len na PBS datasete ktory vyzera ze ho potrebuje, ostatne su relatime

Asi sa nechapeme, aké máš write rýchlosti random a sequence?

podla toho kedy sa pozeram , hodne nekonzistentne:

random write na dataset s 128k recordsize:

Kód: Vybrať všetko

/StoragePool/Storj$ sync; sudo fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --numjobs=8 --size=256M --iodepth=8 --loops=4 --group_reporting
random-write: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=posixaio, iodepth=8
...
fio-3.33
Starting 8 processes
Jobs: 8 (f=8): [w(8)][37.5%][w=2777MiB/s][w=44.4k IOPS][eta 00m:05s]
random-write: (groupid=0, jobs=8): err= 0: pid=3219968: Tue Dec 17 18:36:32 2024
  write: IOPS=49.5k, BW=3096MiB/s (3246MB/s)(8192MiB/2646msec); 0 zone resets
    slat (nsec): min=384, max=4673.8k, avg=2101.65, stdev=23631.89
    clat (nsec): min=486, max=209987k, avg=1126202.86, stdev=4028141.79
     lat (usec): min=11, max=209988, avg=1128.30, stdev=4028.49
    clat percentiles (usec):
     |  1.00th=[    42],  5.00th=[    85], 10.00th=[   106], 20.00th=[   135],
     | 30.00th=[   172], 40.00th=[   217], 50.00th=[   293], 60.00th=[   424],
     | 70.00th=[   644], 80.00th=[  1057], 90.00th=[  2376], 95.00th=[  4686],
     | 99.00th=[ 14091], 99.50th=[ 17957], 99.90th=[ 27919], 99.95th=[ 45876],
     | 99.99th=[196084]
   bw (  MiB/s): min=  360, max= 4798, per=65.73%, avg=2035.00, stdev=235.42, samples=31
   iops        : min= 5771, max=76768, avg=32558.67, stdev=3766.81, samples=31
  lat (nsec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=1.38%, 100=6.48%
  lat (usec)   : 250=37.30%, 500=18.92%, 750=9.22%, 1000=5.79%
  lat (msec)   : 2=9.41%, 4=5.53%, 10=4.09%, 20=1.49%, 50=0.31%
  lat (msec)   : 100=0.02%, 250=0.03%
  cpu          : usr=3.32%, sys=1.81%, ctx=105406, majf=2, minf=253
  IO depths    : 1=4.4%, 2=9.7%, 4=28.4%, 8=57.5%, 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=96.6%, 8=3.4%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,131072,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
  WRITE: bw=3096MiB/s (3246MB/s), 3096MiB/s-3096MiB/s (3246MB/s-3246MB/s), io=8192MiB (8590MB), run=2646-2646msec
molnart@omv6:/St

random write na dataset s 1M recordsize:

Kód: Vybrať všetko

/StoragePool/Games$ sync; sudo fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --numjobs=8 --size=256M --iodepth=8 --loops=4 --group_reporting
[sudo] password for molnart: 
random-write: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=posixaio, iodepth=8
...
fio-3.33
Starting 8 processes
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
Jobs: 7 (f=7): [w(6),_(1),w(1)][25.0%][w=497MiB/s][w=7957 IOPS][eta 00m:15s]
random-write: (groupid=0, jobs=8): err= 0: pid=3223769: Tue Dec 17 18:40:08 2024
  write: IOPS=28.1k, BW=1754MiB/s (1839MB/s)(8192MiB/4670msec); 0 zone resets
    slat (nsec): min=393, max=87737k, avg=2672.16, stdev=244095.34
    clat (nsec): min=350, max=331720k, avg=2051024.12, stdev=7277845.23
     lat (usec): min=17, max=331723, avg=2053.70, stdev=7281.99
    clat percentiles (usec):
     |  1.00th=[    35],  5.00th=[    82], 10.00th=[   108], 20.00th=[   143],
     | 30.00th=[   186], 40.00th=[   225], 50.00th=[   297], 60.00th=[   457],
     | 70.00th=[   848], 80.00th=[  1598], 90.00th=[  5669], 95.00th=[ 11994],
     | 99.00th=[ 19006], 99.50th=[ 27132], 99.90th=[ 88605], 99.95th=[141558],
     | 99.99th=[278922]
   bw (  MiB/s): min=  659, max= 5811, per=98.28%, avg=1724.09, stdev=254.95, samples=63
   iops        : min=10552, max=92988, avg=27582.92, stdev=4079.26, samples=63
  lat (nsec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=1.77%
  lat (usec)   : 100=6.12%, 250=36.13%, 500=17.70%, 750=6.60%, 1000=3.90%
  lat (msec)   : 2=10.00%, 4=5.61%, 10=5.57%, 20=5.69%, 50=0.70%
  lat (msec)   : 100=0.12%, 250=0.05%, 500=0.02%
  cpu          : usr=1.96%, sys=1.13%, ctx=119504, majf=0, minf=177
  IO depths    : 1=4.5%, 2=9.4%, 4=24.2%, 8=61.9%, 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=96.9%, 8=3.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,131072,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
  WRITE: bw=1754MiB/s (1839MB/s), 1754MiB/s-1754MiB/s (1839MB/s-1839MB/s), io=8192MiB (8590MB), run=4670-4670msec

davnejsi random write benchmark, ale netusim kedy ani na aky dataset s akymi nastaveniami (urcite min. 4 mes dozadu)

Kód: Vybrať všetko

sudo fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --numjobs=8 --size=256M --iodepth=8 --loops=4 --group_reporting
random-write: (g=0): rw=randwrite, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=posixaio, iodepth=8
...
fio-3.33
Starting 8 processes
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
random-write: Laying out IO file (1 file / 256MiB)
Jobs: 1 (f=1): [_(1),w(1),_(6)][99.7%][w=8704KiB/s][w=136 IOPS][eta 00m:01s]
random-write: (groupid=0, jobs=8): err= 0: pid=2509217: Tue Aug 20 22:24:02 2024
  write: IOPS=341, BW=21.4MiB/s (22.4MB/s)(8192MiB/383575msec); 0 zone resets
    slat (nsec): min=515, max=1125.0k, avg=2570.98, stdev=6425.54
    clat (usec): min=52, max=1320.3k, avg=175659.42, stdev=110224.35
     lat (usec): min=57, max=1320.3k, avg=175661.99, stdev=110224.45
    clat percentiles (usec):
     |  1.00th=[    611],  5.00th=[   5932], 10.00th=[  31327],
     | 20.00th=[  90702], 30.00th=[ 124257], 40.00th=[ 145753],
     | 50.00th=[ 164627], 60.00th=[ 185598], 70.00th=[ 210764],
     | 80.00th=[ 248513], 90.00th=[ 320865], 95.00th=[ 383779],
     | 99.00th=[ 509608], 99.50th=[ 557843], 99.90th=[ 692061],
     | 99.95th=[ 750781], 99.99th=[1002439]
   bw (  KiB/s): min= 3585, max=585782, per=100.00%, avg=23399.15, stdev=3527.06, samples=5750
   iops        : min=   56, max= 9151, avg=365.47, stdev=55.10, samples=5750
  lat (usec)   : 100=0.01%, 250=0.16%, 500=0.55%, 750=0.51%, 1000=0.34%
  lat (msec)   : 2=1.08%, 4=1.40%, 10=2.14%, 20=2.00%, 50=4.94%
  lat (msec)   : 100=8.91%, 250=58.48%, 500=18.39%, 750=1.05%, 1000=0.04%
  lat (msec)   : 2000=0.01%
  cpu          : usr=0.08%, sys=0.03%, ctx=132431, majf=0, minf=189
  IO depths    : 1=0.1%, 2=0.1%, 4=4.3%, 8=95.6%, 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.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,131072,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
  WRITE: bw=21.4MiB/s (22.4MB/s), 21.4MiB/s-21.4MiB/s (22.4MB/s-22.4MB/s), io=8192MiB (8590MB), run=383575-383575msec

[Chris]

molnart

skus:
fio --name=seqwritetest --ioengine=libaio --rw=write --bs=1M --direct=1 --size=10G --numjobs=1 --runtime=60 --time_based --group_reporting
fio --name=writetest --ioengine=libaio --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --time_based --group_reporting

este raz skusim L2ARC je cache pre READ operacie, na write si cachuje system sam z volnej RAM, ktory ty nemas a swapuje.

SWAP => SMRT

cize zmen si:
ARC daj na minimum 1GB, max 4GB.
recordsize zmen na 64k (kedze mas tam velmi vela suborov pod 2MB)
swapines zmen na 1
compression pouzi max zstd-4(mozno5) alebo aj default zstd
dedup - vypni ak pouzivas
ak mas zapnutu cache na diskoch vypni
checkni ci raid karta je flashnuta/prepnuta do IT , teda HBA modu.

podakuj sa mi

[zoom]

Btw. este tak pomimo k tomu NE02 firmwaru... tu si nejaky jozko pytal presne ten isty a podla editu mu ho niekto poskytol, len par dni dozadu. Tak tam mozes skusit napisat a mas FW rovno pre tvoje disky.

Tu mas dalsiu peknu zbierku pre HGST, aj pre tvoj product number, ale asi ine oznacenie FW, ktore nemusi ist naflashovat.

[molnart]

este raz skusim L2ARC je cache pre READ operacie, na write si cachuje system sam z volnej RAM, ktory ty nemas a swapuje.

preco nemam volny ram na zapis ked som hore linkoval z htop ze je 13 GB volnych napriek ARC cache?

firmware som si nasiel tu: https://files.hddguru.com/download/Firm ... irection=1 ale este som neupdatol. ten co som nasiel od NetApp je za paywallom, HP umoznuje update len v diskovych poliach (tool vyzaduje IP adresu a login), ale da sa zneho extrahovat bin subor ktory by som teoreticky vedel flashnut.