Enne kui võrgu poole vaadatagi, aja fio soojaks ja mõõda nasis kohapeal palju failisüsteem ja kettad läbi lasevad. _________________ Mida Ott ei õpi, seda Egon ei tea.
Pane Syno otse arvutisse ja proovi seda 300-330 MB / s testi uuesti. Väga tõenäoliselt ongi see max perf ketaste ja SHR konfiguratsiooniga. 2690 Mbps on umbes 330 MB / s
Vahepeal oli mahti dd test teha. Write tuli volume kohta 256-264 MB/s. Seega jah midagi SHR2 volume'ga. Tellisin 2 puuduolevat 6TB red pro ketast juurde, et kõik samad oleks, siis mõõdan uuesti.
Vahepeal oli mahti dd test teha. Write tuli volume kohta 256-264 MB/s. Seega jah midagi SHR2 volume'ga. Tellisin 2 puuduolevat 6TB red pro ketast juurde, et kõik samad oleks, siis mõõdan uuesti.
Ootuspärane tulemus ju, mida sa sealt saada tahad ? dd on sul seq read-write. Üldiselt on linuxitel juba meltdowni ajast seq rw omadega p's. Tahad tegelikku tulemust, harrasta parallelismi ja mitte sama os'i (kerneli) piires. Kui tahad reaalsemaid tulemusi, siis võta windows, moundi nas kettana külge ja lase chystaldiskmark selga. ATTO'ga võid ka, toob enamvähem sama tulemuse, aga tõlgendamine on tiba keerulisem, kuna i/o suurused on ka mängus ja sa pole ekspert.
OK, eksperdid. Kas minu server
7x16TB Toshiba Enterprise @raidZ2 (3x 2TB Fikwot FN960 @mirror, metadata) on piiratud 10gb võrkari või ikkagi raid kiiruse poolt? Hetkel on reaalsed kiirused just sellised, et pakkuda võib vist mõlemat.
Ma mõtlen siis suurte failide lohistamisel. _________________ Liitu Binance'ga Liitu Honey'ga
Mis sul siin paralleelselt toimub ? Ühe faili lugemine-kirjutamine on igal juhul järjestikoperatsioon. Edasi tuleb sul veel softiline raid, mida SHR kohe kindlasti on, st parity eriti veel R6 puhul võtab topelt cpu ressurssi (ja seda pole synol just ülemäära palju), kõige all veel lisaks SATA, mitte SAS.
tsitaat:
Ma mõtlen siis suurte failide lohistamisel.
Üks suur fail nagu öeldud, on seq read-write, sellega on viimasel ajal OS'des üldiselt kehvasti. Benchisin oma DS423+ SHR 3x6TB Red Plus. Üks ketas syno enda bench 190MB/s, lokaalne win10 VM ja chystaldiskmark, lugemine 134MB/s, kirjutamine on tiba nali, ehk 545MB/s, aga see tuleb fs cache tõttu, mida syno teatud juhtudel kasutab ja teatud juhtudel mitte, näiteks samba puhul ei. Mul on seal ka üks singel SSD sees, sellega on tulemused vastavalt lugemine 358MB/s ja kirjutamine 334MB/s. Viimane võiks mingi indikatsiooni anda, mis saab siis, kui kasutada pöörlevaid kettaid ja lisada sinna nii softi, kui sata overheadid.
mdraidi parity on see, mis kirjutamisel sul läbi cpu läheb ja nagu öeldud, siis dd ei pruugi tänasel päeval olla enam adekvaatne tööriist selliseks perftestiks.
OK, eksperdid. Kas minu server
7x16TB Toshiba Enterprise @raidZ2 (3x 2TB Fikwot FN960 @mirror, metadata) on piiratud 10gb võrkari või ikkagi raid kiiruse poolt? Hetkel on reaalsed kiirused just sellised, et pakkuda võib vist mõlemat.
Ma mõtlen siis suurte failide lohistamisel.
Kui kirjutatav fail on väiksem kui RAM suurus, siis käib kirjutamine RAM kiirusel
Sealjuures Q32T1 tõmbab CPU (i3-12100) ca 80% peale.
Piirajaks suurte failide korral on mul võrk, aga ega Zpoolil seal palju varu ka pole. _________________ Liitu Binance'ga Liitu Honey'ga
Sealjuures Q32T1 tõmbab CPU (i3-12100) ca 80% peale.
Piirajaks suurte failide korral on mul võrk, aga ega Zpoolil seal palju varu ka pole.
Tee see test nüüd 8GB ja 16GB failidega ka. 1GB on selline asi, mis kipub tänapäeval juba puhvritesse mahtuma. Üldisemalt ka, sata ja parity'ga raid konfid. Tegemist on siiski half duplex asjaga ja veel ühe data lanega, mis tähendab, et üks kirjutamise tsükkel tähendab sisuliselt minimaalselt kahte operatsiooni, millest üks ootab teise taga, kirjutus + pariti (R6x2). Mida rohkem kettaid lisandub, seda hullemaks asi läheb. Võid mõelda, et saad perfi lihtsalt skaleerida, lisades kettaid. Teatud maani jaa, aga piir tuleb tegelikult üsna ruttu vastu, isegi sas konfides kasutatakse enamasti 5+2 raidsete poolides. On nähtud ka suuremaid, aga need on tootjaspetsiifilised eriandid.
Ehk synologi NAS-idel see 10Gb ühenduse mõte on mis, kui ühegi nipiga seda kiirust ei saavuta, jääb üle ainult et kiire nett NAS-is abiks kui sinna tõesti need tuhanded korraga pöördujad tekivad mida syno oma spetsifikatsioonis erinevatel teenustel max kasutaja arvuna näitab.
Suvel sai ka natuke pusitud 10Gb PC-switch-NAS, jäi samuti maksimaalseks kiiruseks sinna 5Gb kanti.. kuna seadmed eri ruumides ja võrgukaabel isepusija otsastatud CAT5e, panin selle süüks. Sai TEMU-st mõned CAT6 ka CAT7 valmis kaablid tellitud, et kolin PC testiks muule kolale lähemale ja vaatab kuidas tehasekaablitega kiirused jooksevad.. selleks ajaks kui kaablid kohale jõudsid, läks 10Gb pusimise tuhin üle..
Nüüd seda teemat lugedes, mu mõte kaabliteemal ei tarvitsegi pädev olla, NAS-i enda ketastekiirused tõepoolest mängivad ju samuti rolli
Mõtlen nüüd kuidas uuesti testida kodust 10Gb võrku, kui 10Gb võimelised ainult need PC - switch - NAS, kas PC-switch-PC oleks võimalik, ma neid võrgu peensusi ei jaga ka..
Veel jäi mõte pidama mu syno DS923+ on USB 3.2 aga kuna need Gen 1 pordid, siis vist sealt ka max 5Gb - muidu oleks mõelnud miski ssd või mälupulga USB-i, mis peaks HDD asjadest kiiremini "pöörlema" ja faili kirjutamist&lugemist sinna mõõtma.
Tundub, et see 10Gb kodus on 'overkill', isegi testida ei saa/oska mida võrk võimaldaks.. _________________ ---
Mis sa sest võrgust testid, kas on mingi kahtlus, et korraliku kaabelduse korral ei tule 10G täis ? Tuleb küll, aga kas sul sinna midagi külge ka panna on, see on iseasi.
Prillpapa, vaata ülevalpool mu posti, ise saad oma lokaalse kiirusetesti hostida, mis kettaid üldse ei puuduta.
Väheamalt R6 seq read peaks lihtsamini defineeritud olema aga tundub, et mul read ka pekkis Vähemalt näiteid / kalkulaatoreid vaadates 6-8 disk R6 peaks 10G lingi suutma ära kasutada.
dd if=/volume1/data/benchmark_test/testfile of=/dev/null bs=1M
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 74.7555 s, 287 MB/s
Prillpapa, vaata ülevalpool mu posti, ise saad oma lokaalse kiirusetesti hostida, mis kettaid üldse ei puuduta.
Väheamalt R6 seq read peaks lihtsamini defineeritud olema aga tundub, et mul read ka pekkis Vähemalt näiteid / kalkulaatoreid vaadates 6-8 disk R6 peaks 10G lingi suutma ära kasutada.
dd if=/volume1/data/benchmark_test/testfile of=/dev/null bs=1M
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 74.7555 s, 287 MB/s
Sa nagu põhimõtteliselt ignoreerid kõike, mida ma siin räägin ? Sinu tulemus dd'ga on ootuspärane niimoodi testides. Kas sa üritad saada midagi enamat, kui ma oma enterprise keskkonnas ? SATA ketastega synoga ? Naljamehed ikka.
Markos, ma nagu ootaks sama, mida teised saanud on kätte. Mulle lihtsalt veel ei jõua kohale, mida ma ei mõista selles osas.
Sa ei tea, kes ja kuidas täpselt testinud ja palju seal vassimist on. Kui üle võrgu kasti ram'i vuristad, siis saadki oma 10G täis. Nägid mu linuxi näiteid ? Synos jookseb misasi ? Saad aru, milles muuhulgas probleem on ?
No ma ei tea, alustan oma põhitõdedest. Palun lükake ümber kui midagi on mäda, siis ma saan aru ehk kus midagi valesti läheb.
(räägime kõik seq operatsioonidest, random ei koti väga kuna mul kõik 10-100GB failid, seega nvme cache ka ei rakendu).
R6 write ma pidasin: (disc count - 2) * avg single disk write. Tuleb välja et see on siis throughput? ja IOPSidel on ikka speed factor 1.
R6 read ma pidasin: disc count * avg single disk read.
HW poole pealt võtan testimisel resource monitori lahti, näen et resu praktiliselt ei kasutata.
Networki testid tegin ära, see on selgelt kõrgem, seega sinna midagi taha ei jää.
Sa nagu põhimõtteliselt ignoreerid kõike, mida ma siin räägin ?
Su jutt on osalt õige, aga peksad ülbelt segast ka või arusaamatult seostatud juttu, näiteks
Markos kirjutas:
Tahad tegelikku tulemust, harrasta parallelismi ja mitte sama os'i (kerneli) piires. Kui tahad reaalsemaid tulemusi, siis võta windows, moundi nas kettana külge ja lase chystaldiskmark selga.
Las inimesed uurivad ja puurivad.
RassK, hardware RAID6 ja Syno SHR2 võibki väga erinev perf olla. SHRis on väidetavalt diskid partitatsioonideks tehtud, mille peale (mitu) md raid device tehtud ja need omakorda LVM gruppidesse pandud. Kui sellel veel omakorda ext4 journal peal on, siis see vähendab ka perfi https://www.kernel.org/doc/html/latest/filesystems/ext4/journal.html
No ma ei tea, alustan oma põhitõdedest. Palun lükake ümber kui midagi on mäda, siis ma saan aru ehk kus midagi valesti läheb.
(räägime kõik seq operatsioonidest, random ei koti väga kuna mul kõik 10-100GB failid, seega nvme cache ka ei rakendu).
R6 write ma pidasin: (disc count - 2) * avg single disk write. Tuleb välja et see on siis throughput? ja IOPSidel on ikka speed factor 1.
R6 read ma pidasin: disc count * avg single disk read.
HW poole pealt võtan testimisel resource monitori lahti, näen et resu praktiliselt ei kasutata.
Networki testid tegin ära, see on selgelt kõrgem, seega sinna midagi taha ei jää.
Ma enam vähem olen arvutanud oma jukufaktoriks ~50%, ehk siis tulemus võiks olla pool sarnastest (võrreldavamatest) näidetest.
Veelkord sata puhu ei saa sa lihtsalt korrutada, half duplex, mäletad. Ühe faili puhul ei käi seq read ja write nii nagu saa arvad. Striping annab sulle throughtputi ja eelise mitmete üheaegsete lugemiste ja kirjutamiste korral (eriti, kui sul on sas, mitte sata). Kui ühe ketta IO on hõivatud parasjagu teise operatsiooniga, siis teine vaba ketas saab samaaaegselt teha midagi muud, sealt tuleb perfi tõus. Enterprise kastides moodustatakse raid levelid mitte üksikutest ketastest, vaid seal on lihtsalt jbod, mille peale on laoatud chunkletid ja neid jagatakse siis raid levelitesse erinevate diskide peale, ning taustal pidevalt i'od arvesse võttes ka defragmenteeritakse, et saada io mõistes optimaalseim jaotus ja vältida hotspotide teket.
Põhimõtteliselt saad omal benchi ka nii testida, et paned synosse vabasse slotti mõne ssd ja siis teostad vastastikkuseid kopi operatsioone. Aga tee seda suurte failidega, sest seal sööb cache faktor tugevalt sisse ja arvesta, et see jagab siiski sama sata kontrollerit. Testisin endal ära, tulemused on samad, mis crystaldiskmarkil ja miks ei peakski.
tsitaat:
Tahad tegelikku tulemust, harrasta parallelismi ja mitte sama os'i (kerneli) piires.
Paralleelne lugemine/kirjutamine erinevate tarbjate poolt välistamaks os'i enda (kerneli) piiranguid. Maakeeli, testi korraga mitmest arvutist.
tsitaat:
SHRis on väidetavalt diskid partitatsioonideks tehtud, mille peale (mitu) md raid device tehtud ja need omakorda LVM gruppidesse pandud. Kui sellel veel omakorda ext4 journal peal on
SHR ongi mdraid + lvm ja ext4 või uuemal ajal btrfs on maitseküsimus, mina kasutan viimast ja selle mõju perf tulemustele on antud kontekstis küll täiesti olematu.
ok, ma sain aru, et see dd annabki teoreetilise maksimumi aga nüüd CrystalDiskMark'i tehes Windowsist, millele üle smb3 on mapitud share annab reaalses elus kõrgemad tulemused
Lisan ühe pildi. Ühel juhul siis cache aktiivne ja teisel mitte. NAS-is on sees ka 980 Pro ja 970 Pro SSD. Neid testisin ka. Pildi pealkirjast näeb mis on mis.
QNAP NAS kus 6x 4TB (ST4000NE001) ketta RAID5 ja mingi Inteli 2 pordiga võrgukas.
Windows 11 lauakas kus sees Edimax EN-9320SFP+ võrgukas.
Mõlemad on ühendatud Ubiquiti USW-Aggregation taha.
sa ei või postitada uusi teemasid siia foorumisse sa ei või vastata selle foorumi teemadele sa ei või muuta oma postitusi selles foorumis sa ei või kustutada oma postitusi selles foorumis sa ei või vastata küsitlustele selles foorumis sa ei saa lisada manuseid selles foorumis sa võid manuseid alla laadida selles foorumis
Hinnavaatlus ei vastuta foorumis tehtud postituste eest.
:: KKK
:: otsing 
:: statistika
:: kasutajate nimekiri
:: kasutajate grupid
:: registreeri
teata moderaatorile
mõned CAT6 ka CAT7 valmis kaablid tellitud, et kolin PC testiks muule kolale lähemale ja vaatab kuidas tehasekaablitega kiirused jooksevad.. selleks ajaks kui kaablid kohale jõudsid, läks 10Gb pusimise tuhin üle..
