|
|||||||||||
23.04.2025., 16:28
|
#92 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Nastavio sam dalje sa testiranjima, cisto iz znatizelje... Napravio sam 2x2GB RAID0 RAMDisk NTFS baziran na DDR5-5200 RAMu i gledam gdje cu naletiti na bottleneck... Koristio sam RAID0 od Windowsa jer je to jedini nacin za napraviti ovaj eksperiment... U ovom slucaju ne mogu koristiti FAT32, tako da sam koristio NTFS sa defaultnim block sizeom... Naravno, rezultati su bezvezni i ne mogu dobiti vece brzine nego sto sam jucer dobijao sa jednim 2GB RAMDisk NTFS... Zapravo, dobijam cak i manje brzine sto je i razumljivo s obzirom na overhead koji Windowsi ubacuju zbog softRAID polja... Sve u svemu, rezultat je takav da slaganje softRAID0 polja na RAMDisku nema nikakvog smisla... Napominjem, ovo je bio eksperiment i ideja je bila pokazati sto se moze ocekivati... Drugim rijecima, ukoliko treba doci do poboljsanja, to nije na ovaj nacin... Side by side, jednostruki RAMDisk vs softRAID0 RAMDisk...    
__________________
Zadnje izmijenjeno od: calypso. 23.04.2025. u 17:20. |
|
|
|
23.04.2025., 17:09
|
#93 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Isao sam dalje testirati, ovaj puta allocation unit size na razlicitim filesystemima... Testirao sam default 4kB vs 16kB na FAT32 i isto tako default 4kB vs 16kB na NTFS... Za NTFS sam napravio jos dodatni test sa 64kB allocation unitom da vidim kuda to ide... Kod FAT32 testiranja je vidljivo povecanje i bandwidtha i throughputa u slucaju veceg allocation unita, sto je bilo i za ocekivati... Dokazano je da je 16kB velicina allocation unita na FAT32 bolji izbor za performanse nego defaultnih 4kB, no to onda vuce druge probleme vezane za jako neefikasno koristenje diskovnog prostora... FAT32 allocation unit test side by side - 4kB (default) vs 16kB     Kod NTFS testiranja je situacija malo skliska, tako da je na 16kB vidljivo povecanje bandwidtha i throughputa na nizim IO blokovima, onda malo pada tamo prema velicini bloka od 1MB i onda je do najvecih velicina blokova od 64MB i dalje u prednosti nad 4kB default allocation sizeom... Sto kako i zasto se to desava, ne znam... Na kraju je prikazano ponasanje sa 64kB allocation size da se vidi kuda sve to vodi, a izgleda da ne vodi nikud... Konacni zakljucak - 4kB sweet spot za NTFS... NTFS allocation unit test side by side - 4kB (default) vs 16kB    
__________________
|
|
|
|
|
23.04.2025., 18:03
|
#95 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
__________________
|
|
|
|
|
23.04.2025., 19:23
|
#96 | |
|
Premium
Datum registracije: Sep 2006
Lokacija: Zagreb, Črnomerec
Postovi: 2,483
|
Citiraj:
Jebotepas calypso, na stranu sad projekt sam po sebi, ali odakle ti toliko vremena  . Odakle ti ta sloboda da do pola 3 ujutro testiraš razlike između ntfsa i fata32 i razlike po ramdisk cluster size-u  Otkrij mi tajnu |
|
|
|
|
|
23.04.2025., 20:02
|
#97 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
Nemam radno vrijeme... Radim kad mi se radi ili kada imam posla ili kada trebam biti na sastaku... S obzirom da radim za storage vendora, svi ovi rezultati su mi korisni kod smisljanja novih produkata ili use caseova za postojece produkte... A i dobro dodje da si malo ponovim koristenje ATTO Disk Benchmarka... Cilj ovog eksperimenta sa RAMDiskom je bio pronaci nacin kako prebaciti cache/temp foldere (dakle potpuno nebitne stvari) na RAMDisk... Ujedno, zelio sam provjeriti da li ce se ista ubrzati... Odokativno, osjetim da su neke stvari malo brze, ali ne znam sa cime bih to izmjerio... Ivo_Strojnica je predlozio da provjeri da li mu se brze ucitavaju web stranice pa eto, kada on to rijesi ce valjda i dati neke rezultate... Ja sam odlucio ici na hardcore rezultate koristeci ATTO Disk Benchmark koji je u storage industriji de facto standard za testiranje performansi diskovnih sustava... Dalje sam nastavio sa eksperimentom da vidim sto sve mogu dobiti i kolike cu brzine dobiti u citanju/pisanju na razlicitim memorijskim tehnologijama (DDR4 i DDR5)... Recimo, DDR5 moduli po defaultu rade u dual-channel modu pa se vide velike razlike u odnosu na DDR4... Dalje sam isao usporediti FAT32 vs NTFS po pitanju performansi... Pa sam otisao korak dalje i provjerio sto cu dobiti uz razlicite velicine allocation unita na oba filesystema... U mix sam dodao i ReFS cisto da vidim kako to radi i sta se sa time moze... Svjestan sam da je NTFS puno bolji filesystem, no za nebitne stvari (ephemeral data) poput TEMP/Cache/Scratch gluposti uopce te napredne stvari ne dolaze do izrazaja, vec se traze najbolje performanse... Mislim, koji ce mi djavo journaling, kompresija i ostale gluposti ako trebam scratch file za Photoshop ili Audacity sa kojim cu zavrsiti za 15 minuta? Eno, trenutno kolega pokusava istestirati kako ce mu DeepSeek AI raditi sa 4GB RAMDiskom jer mu se sve vuce preko NVME diska... Sto se moje malenkosti tice... 25 godina se bavim proucavanjem storage sustava, filesystema, backupa, arhiviranja, storage virtualizacijom... Od 2006 se bavim dizajnom i prodajom diskovnih sustava, radio sam za EMC i Veritas distributere i partnere u Hrvatskoj... Imao sam pristup dokumentaciji kojima normalni korisnici nemaju pristup, nacitao sam se whitepapera, tech guideova, Veritasovih Yellowbookova... Zadnjih 6 godina radim za storage vendora (ne, nije Infortrend) koji u portfelju ima produkte za storage virtualizaciju, davno smo bili partner od Violin Systems... EMC i Hitachi su koristili nase tehnologije u svojim specijaliziranim diskovnim sustavima, itd... To je samo storage dio price, a o virtualizaciji i cloudu ima jos veci dio price s obzirom da jos od pocetka 2000tih proucavam virtualizaciju kao koncept... Od 2007. sam se bavio prodajom VMware produkata, digao jednog lokalnog partnera na VIP Premier level jos tamo 2009 godine (800.000 EUR VMware prodaja 2008 godine), nakon toga 2010. presao u cloud vode, vodio IT odjele u firmama od 1200 i 3000 ljudi gdje se vrtilo par tisuca VMova u AWSu, odradio preko 50 cloud migracija u AWS i VMware vCloud (to je kada uzmes servere iz datacentra, virtualiziras ih i prebacis u cloud)... Tada se jos nije znalo niti sto je to cloud, a jos manje kako se prebaciti u cloud... Odradjivali smo online migracije, offline migracije, realtime migracije sa alatima koji su tada bili dostupni... Odradio vjerojatno jednu od prvih cloud migracija u VMware vCloud ikad o kojoj je napisan customer use case svojedobno, to je bilo 2010... Trazili smo od AWSa da prime diskove koje im saljemo pa su morali osmisliti za nas nacin kako da prime diskove, iz cega je kasnije nastao AWS Snow-family servis koji sluzi za slanje velike kolicine podataka u AWS... Rekao sam prije - zaboravio sam vise stvari nego sto su mnogi forumasi ikad znali o storage tehnologijama... Ako koga zanima sto sam 2010 pisao o Enterprise Flash SSDovima i TBw u vezi kojih me nedavno jedan forumas prozivao, evo tu je prezentacija... Mislim, ne razumijem zasto se mene proziva da ne znam osnove osnova... https://www.slideshare.net/slideshow...drives/5455798 Tako da svo ovo prozivanje od strane doticnih je ispod svakog ljudskog nivoa... Srecom pa sam otkrio ignore i kako ih staviti na ignore...
__________________
Zadnje izmijenjeno od: calypso. 23.04.2025. u 20:09. |
|
|
|
|
|
23.04.2025., 20:57
|
#99 |
|
Premium
Datum registracije: May 2006
Lokacija: München/Varaždin
Postovi: 4,649
|
Calypso svaka cast na volji ali da nisi malo zaglibio u Burnout vode? |
|
|
|
|
23.04.2025., 22:00
|
#101 | |
|
Premium
Datum registracije: May 2006
Lokacija: München/Varaždin
Postovi: 4,649
|
Citiraj:
A jesi naso temu  Yep :P |
|
|
|
|
|
23.04.2025., 22:09
|
#103 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
Trebalo bi to nekako istestirati, no nemam pojma jos na koji nacin... Idem bas probat ukljucit kompresiju na NTFS RAMDisku pa javim rezultate prije i nakon kompresije... Bas me zanima sta ce se desiti sa throughputom (IOPS)...
__________________
|
|
|
|
|
|
23.04.2025., 22:23
|
#105 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
__________________
|
|
|
|
|
|
23.04.2025., 23:29
|
#106 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Zavrtio sam test... 2GB NTFS volume sa i bez kompresije... Testirano na DDR4-2400 baziranom RAMDisku... Rezultati su prilicno zanimljivi kod kompresije - read je doslovno 2x brzi, dok write bolje da ni ne spominjemo koliko je katastrofalno spor... Sutra cu zavrtit na DDR5-5200 pa da vidim kako se tamo ponasa... Edit: Sad kad sam se malo naspavao sam vidio da je read uduplo brzi na malim velicinama bloka (block size), do 4kB... E nakon toga pada i read performanse...    
__________________
Zadnje izmijenjeno od: calypso. 24.04.2025. u 10:43. |
|
|
|
|
24.04.2025., 10:45
|
#107 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Testirao sam danas performanse 2GB NTFS volume sa i bez kompresije... Testirano na DDR5-5200 baziranom RAMDisku... Opet ista prica kada se kompresija ukljuci - kriminalno spor write, ali read je uduplo brzi nego bez kompresije do nekih 4kB block size, nakon toga pomaka nema...    
__________________
|
|
|
|
|
24.04.2025., 12:45
|
#108 |
|
Premium
Datum registracije: Sep 2018
Lokacija: tu
Postovi: 3,298
|
Sad si i mene zarazio s ovim glupostima Jučer sam htio vidjeti kako se ponaša tempfs vs ramfs. Koliko ja vidim na DDR4 3200 bi max trebalo biti teoretskih 25.6 GiB/s. Neki benchmark koji sam odradio kazuje da je to kod mene zapravo 17.4.tempfs i ramfs daju max 2.8 GiB/s (sekvencijalno), tako da sve ovo i nije netko pretjerano mjerilo. Čitam da ta dva *fs nisu niti rađeni u svrhu maksimalnih performansi, što ima smisla. Približno iste performanse imam na NMVE, 2.5 GiB/s. Sve te rezultate mi je dao dd, pretpostavljam da /dev/null nije usko grlo. Kada u RAM napravim file i formatiram ga kao BTRFS i onda to mountam kao disk, dobijem max 1.1 GiB/s. Ako isti "disk" mountam sa kompresijom, brzina ode na 1.5 GiB/s. Pričamo sekvencijalno. Koliko to sve skupa ima smisla, vjerojatno nema niti najmanje Budem kasnije napravio par rsync testova, zanima me kako se ponaša sa hrpom malih fajlova.
__________________
|
|
|
|
|
24.04.2025., 13:36
|
#109 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Xexe Svidja mi se da cemo na ovoj temi imati hardcore rezultate raznih testova RAMDiska... Ovo sa rsync i ponasanjem na hrpi malih fajlica je zapravo jako zanimljivo... Jos da Ivo_Strojnica odradi svoje Apache testove brzine ucitavanja web stranica... Danas ili sutra kad ulovim vremena cu jos ponoviti testove sa 'Bypass write cache' ukljucenim da vidim kakvi ce onda biti rezultati...
__________________
|
|
|
|
|
24.04.2025., 14:23
|
#111 | |
|
Premium
Datum registracije: Feb 2007
Lokacija: Istra
Postovi: 3,458
|
Citiraj:
Ček da probaš rsync s hrpom malih datoteka i puno hardlinkova Naročito target FS se malo napati kod toga. |
|
|
|
|
|
24.04.2025., 14:41
|
#112 |
|
Premium
Datum registracije: Nov 2004
Lokacija: Velika Gorica
Postovi: 1,513
|
Kad vec volis zanimljive testove, evo jednog na Linux serveru. Skaliranje throughputa ovisno o broju NVMe diskova. Propusnost je u GBytes/sec, a dole je broj diskova. I graf 'idealno' vs 'realni svijet'. 112 GBytes/sec je bez obzira na to poprilicno impresivna brojka 
__________________
Idiocracy. Kad satira postaje stvarnost. |
|
|
|
|
24.04.2025., 14:54
|
#113 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
Znam da je ogroman problem izbacit sve to van prema mrezi i da se radi na razoju NVMeOF za takve stvari, no i taj ima svojih problema... Prica se o 100Gbps, no to je Gigabita u sekundi, al kako izvuci jos 10x vise od toga, znaci 1Tbps, to nemam pojma... Infiniband? RoCE?
__________________
|
|
|
|
|
|
24.04.2025., 15:05
|
#114 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Usput, vidim da se dosta mijesaju termini bandwidth i throughput od vendora do vendora... U mom slucaju, bandwidth je MB/s, dok se throughput mjeri u IOPS... To je EMC skolica i tako se u njihovom svijetu oznacavaju stvari... Vidim da drugi navode da je bandwidth teoretska brzina prijenosa, dok je throughput realna brzina prijenosa u MB/s... EMC terminologija - https://www.dell.com/support/kbdoc/e...ce-terminology IBM Cloud terminologija - https://cloud.ibm.com/docs/vpc?topic...ty-performance
__________________
|
|
|
|
|
24.04.2025., 15:19
|
#115 |
|
#erase startup-config
Datum registracije: Nov 2001
Lokacija: Zagreb
Postovi: 3,630
|
Ima jedna stvar kod sekvencijalnog throughputa. PC storage koristi DMA kontroler za prebacivanje podataka sa storagea preko PCI(e) sabirnice direkt u RAM i obrnuto. S druge strane RAM drive koristi CPU za prebacivanje podataka, opterećuje ga i može ga zakucati odnosno bar jedan core za jedan kontinuirani stream. Zato brzi storage ekšli može imati veći throughput od RAM drivea. |
|
|
|
|
24.04.2025., 15:50
|
#116 | |
|
Premium
Datum registracije: Nov 2004
Lokacija: Velika Gorica
Postovi: 1,513
|
Citiraj:
Imao prilike za probati, pa probao koliko ide (nije da bas svaki dan imas server sa 20 x NVMe diskova) Isto tako server je imao 2x dual-port 100GBps kartice. I koliko god da djeluje to fora, napuniti taj bandwidth izmedju dva servera je poprilicna nauka. Uspio natjerati kojih 70Gbps sa iperf-om na 100Gbps interface-u, ali vise nije htjelo...
__________________
Idiocracy. Kad satira postaje stvarnost. |
|
|
|
|
|
24.04.2025., 16:13
|
#117 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
Cak i sa TCP offloadingom, unosis latencije koje su vidljive na tim brzinama...Probaj sloziti NVMeOF ako mozes preko toga tako da sibas NVMe protokol preko te mreze nekako... U svakom slucaju zanimljivo, iako ne znam sta ce ti takvo sto za Ceph... Vise bi smisla imalo uzeti malo vise manjih servera sa diskovima manjih kapaciteta i sloziti ih u Ceph cluster... A i pitanje je sto mozes dobiti na Cephu ako ces ga koristiti kao block device... Ceph je primarno object storage preko kojeg se lijepi block storage ili file storage... Tako da i tu imas jos malo overheada... Casna rijec, sad me bas zanima kako bi radio Ceph na RAMDisku...
__________________
Zadnje izmijenjeno od: calypso. 24.04.2025. u 16:26. |
|
|
|
|
|
24.04.2025., 16:15
|
#118 | |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Citiraj:
Onako, baratanje sa sicusnim podacima, no tek to bi trebalo ubiti CPU onda...Ajd budem izvrtio malo kasnije par testova bas da vidim sta se sa CPU desava...
__________________
|
|
|
|
|
|
25.04.2025., 00:54
|
#119 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Gledam CPU usage dok testiram sa ATTO Disk Benchmarkom, nema nikakvih spikeova niti mi zakucava jednu jezgru, malo podigne frekvenciju procesora (sa 1GHz na 1.5GHz u prosjeku) i to je to... Znaci doslovno nista se ne desava...
__________________
|
|
|
|
|
25.04.2025., 01:12
|
#120 |
|
Premium
Datum registracije: Oct 2002
Lokacija: Zagreb/Rijeka
Postovi: 1,930
|
Jeli itko probao koristiti RAMDisk za lokalni AI deployment tipa DeepSeek ili nes slicno? Postavio sam upit onom drugom statistickom pogadjalu (DeepSeek, jel...) za sto bi se dalo koristiti RAMDisk kod lokalne instalacije i ovo mi je napisalo... What DeepSeek Can Use the RAMDisk For Model Cache: - Store frequently accessed model weights (if using llama.cpp or similar). Temporary File Storage: - Store intermediate files (logs, tokenized inputs). Swap for Small-Batch Inference: - If your system has limited RAM, a RAMDisk can help avoid SSD thrashing. Faster Disk-Based KV Caching: - Some inference engines allow offloading cache to disk - use RAMDisk for speed. Best for: - Small models (e.g., deepseek-coder-1.3b in 4-bit) that fit entirely in RAMDisk. - Frequent disk I/O tasks (like caching prompts).
__________________
|
|
|
|
 |
|
|
