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 Opencode Go soodsa coding plaaniga ja saa 5€ soodust! Liitu Wise'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.
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.
Kui nüüd aus olla, siis vaadates Markos'e kalli enterprise NASi perfi ja neid viimaseid, siis ma ei saa midagi aru.
edit: lisaks ma ei saa aru, miks siia tuua üldse SATA vs SAS. HDD'd ei suuda nagunii seda linki lähedaltki umbe tõmmata.
Kallis enterprise oli tõestuseks selle kohta, et dd meetod ei ole õige, ka kalli ja vägagi võimeka infra peal tulevad suhtkoht sama nirud tulemused, mis sul soho nas's, ehk siis piirang on OS'i poolel nagu juba mainitud sai. Kui seda kallist enterpriset õigetmoodi benchida, siis tõmbab 2x32GB FC lingid ka umbe, selles pole probleem.
Lasin ka dd'ga otse synos, ja tulemused on:
dd bs=1k count=10M if=/dev/zero of=testfile conv=fsync
10485760+0 records in
10485760+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 75.9929 s, 141 MB/s
dd if=testfile of=/dev/null
20971520+0 records in
20971520+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 18.8482 s, 570 MB/s
Siin cache lollitab ära, kuna nas'l on 18GB RAM ja seal suut midagi muud pole, siis on seda vabalt võtta fs cacheks.
Teeme testi suurema failiga:
dd bs=1k count=20M if=/dev/zero of=testfile conv=fsync
20971520+0 records in
20971520+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 153.839 s, 140 MB/s
Kirjutamine sama, aga miks see peakski muutuma.
dd if=testfile of=/dev/null
41943040+0 records in
41943040+0 records out
21474836480 bytes (21 GB, 20 GiB) copied, 91.0158 s, 236 MB/s
Tõehetk, cachest polnud enam abi.
SATA vs SAS puutub asja niipalju, et need tehnoloogiad on määrava mõjuga perfile, kui me kasutame RAID konfe. Sa ei saa kasutada lihtsalt kordajaid perfi arvutamiseks sata puhul. Liidese enda läbilaskevõime on lihtsalt mingi raw suurus, tegelik infovahetus on hoopis midagi muud. Tuleks endale selgeks teha, mida eri kihid andmevahetuses teevad, siis saab pilt selgemaks, ei ole nii, et keerame kraani lahti ja tuleb.
tsitaat:
Tehke ramdisk ja proovige sellega, kas saate 10gbit kätte icon_wink.gif
Miks ei peaks, aga probleem ei ole ju selles. Keegi ei saa oma nelja kettaga synost 10G linki täis, ei peagi saama, kui me räägime pöörlevate ketaste kontekstis.
Ühesõnaga Syno enda sees ma ei saagi siis lihtsalt volume throughputi kätte (puhas raid + OS)? ... see dd nagu tundus ainus olemasolev tööriist. Ma tahan minna step by step ja näha kus see bottleneck siis tuleb.
Lõpuks leidsin siis midagi ametlikku ka, mida paberil lubatud on.
link
DS1621+ | R5 Read: 861 Write: 845, 4TB Syno enda kettad.
Ma saan aru, et siin R5 aga no enam kui kahekordne vahe?
fio utlityt pole Synol? kasutage bs N * 4k, soovitavalt failisüsteemi block või md raid chunk N kordset suurust
tsitaat:
-c, --chunk=
Specify chunk size of kibibytes. The default when creating an array is 512KB. To ensure compatibility with earlier versions, the default when Building and array with no persistent metadata is 64KB. This is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10.
RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power of 2. In any case it must be a multiple of 4KB.
A suffix of 'M' or 'G' can be given to indicate Megabytes or Gigabytes respectively.
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
Peale seda, kui kõik 10GB seadmed on olemas, siis kuskohast internet tuleb? Kui palju 10GB neti omamine igakuiselt maksab?
Ja mida te reaalselt teete sellega ? Avate oma datacentri või ? Isegi 1G on enamikel juhtudel KODUSEKS tarbimiseks overkill.
A mis see kellegi teise asi on, mida ta sellega teeb? Teeb mida tahab. Keegi kuskil arvab ka et isiklik auto on overkill, oma maja on overkill, kraanist tulev soe vesi on overkill, külmik on overkill jne
Ma ei usu, et siin teemas kellelgi 10G välislink on. Valguskaabliga kodus Telialt saab küsida... ilmselt see hind meeldiv ei ole kui üldse pakutakse. Pigem kuskil serverikeskuses racki rentida, kuuldavasti Hüürus saab ka 100G.
Ma olen neid päris mitmesse kasti pand. Aga kindlasti koos NF-A4x10 vendiga. Pole nurisemist olnud.
Muidu pidavat lihtsalt lämbuma jah. _________________ suck less | no slop grenade
Ma arvasin, et see oli Priit, aga tegelikult oli Tõnu,
Vaatasin just, et radikas maha ja 0.5mm vaskplaadi võiks radika ja kiibi vahele panna lisaks. Siis peaks passiivselt ka kannatama. Noctua läheb sinna nipukatega või on vähe viisakamaid viise ka?
Vahepeal jälle veits edasi arenenud, ruuter (RB5009UG) ja switch (CRS328) saanud 10G, desktop saanud 10G, NAS 10G ja Epyc server 10G. VLANid on püsti.
Nüüd VLANidega seoses küsimus. Kuna see ruuter pole suuteline L3HW jaoks (ilmselt pole tal pointigi?) ja switch on, siis inter-vlan routing switchis paika panna tähendab seda, et switch peab ka VLAN firewalliks hakkama (milleks pole jälle switch mõeldud)?
Samas VLANis sai server ja desktop 9G ühenduse, läbi ruuteri (erinev VLAN) 5G ja sööb veerandi ruuteri CPUst
Kirjade järgi peab see ruuter 10G ruutimisega hakkama saama. https://mikrotik.com/product/rb5009ug_s_in#fndtn-testresults Seda ta ei tee küll rauas, vaid protsessori peal. Mitte et poleks pointi, vaid ülesande olemus on teistsugune. Switchimine on väga spetsiifiline, aga lithne töö, ja seega on lihtne tulema, et switchikiibile seda tööd suures või täies mahus sisse ehitatakse. Müürimine langeb üldotstarbeliste arvutuste alla ja jääb seega protsessori selga. Tõsi, mitte täiesti üldotstarbeline, ja palju suurem raud teeb seda hoopis ASICute peal, aga see on hoopis teine maailm.
Igatahes, purgi läbilase sõltub olulisel määral sinu tulemüüri reeglitest ja paketi suurusest. Alusta oma testimist ilma müürita ja täissuuruses paketiga, ja vaata sealt edasi. Iseasi, kas server peaks üldse asuma teises vlanis kui tema kliendid - minu vastus on pigem ei, eriti suure andmesidemahuga server.
Switch ei ole tõesti mõeldud müürima, selle jaoks on ta protsessoriga täielikult alavarustatud. Switch oskab vlanide vahel acl teha, mis sobib kahe ülesande jaoks - vlanide vahel liikluse täielikuks lubamiseks või täielikuks keelamiseks. Igasugune täpsem seadistamine kuulub tulemüürile. _________________ Mida Ott ei õpi, seda Egon ei tea.
Desktop on mul sisuliselt Management VLANis ja Epyc istub Servers VLANis. Lisaks IoT kuhu lähevad võrguseadmed, mis sisuliselt peaks "üksikkongi" minema. Iseenesest desktopi probleemi peaks saama ka nii lahendada, et selle lisa 10G võrguka määrab ainult Servers VLAN route jaoks ja defaultina kasutaks integreeritud 1G oma edasi. Siis peaks ilmselt kaduma ka teoreetilised 9000 vs 1500 MTU konfliktid (hetkel pole veel ühegi otsa sattunud).
Hetkel testid ilma müürita, veel pole seda jõudnud ehitada. Näen, et cpu saab korralikult pihta 10G iperf3 testiga aga resu nagu puudu ei tohiks jääda, et ainult 5G alles jääb
Ise võtsin M2 5Gbit kaardi ei tahtnud 10G eest 100 ära anda. Mingi jahutusega veel jamama. Tuleb aeg kus nedele ei pea fan jahutus enam olema. 5Gbit saab kätte 20ish. 10G tundub täiesti lagi olevat siiski lahjemad on odavamaks läinud. _________________ Punktkeevitus patareidele/akudele. Akutrelli/laptopi/e-bike. PM
Ma oleks võtnud M2 M key kaardi ka 10nese kuid arvutis pole ruumi tahan wifi tagasi panna koos BT. Kui SB AE5 poleks arvutis siis oleks olnud mõeldav. M2 võrgukaart ainus valik mis järgi kuid 100 rahi ma nendele anda hetkel ei taha. SFP peale juba mõtlesin. Tulevad ka need 10nese hinnad varsti alla nagu SFP. Siiski viiesed on juba ok hinnaga. _________________ Punktkeevitus patareidele/akudele. Akutrelli/laptopi/e-bike. PM
Ma olen ka proovinud igatepidi ja lõpuks oli jah, et RAMDisk-i kasutades saavutas küll 1GB/s kiiruse. Võrgukaardi seadeted oli vaja selleks miskit muuta. Youtubes keegi rääkis sellest aga kre enam ei leia üle seda. Oli see äkki Linus või keegi teine. Igatahes midagi sellist oli aga mitte päris see - https://youtu.be/D03t890dKTU?t=370
Mäletan, et kindlasti ei tohtinud kasutada jka DHCP vaid vaja oli fix võrguaadressi.
Kui dhcp sellist asja mõjutab, siis on midagi ikka väga valesti. Pane selle tüübiga aken kinni ja otsi edasi. _________________ Mida Ott ei õpi, seda Egon ei tea.
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..
Spoiler 
