lol calypso to sto je sustav stohastican ne znaci da je random, sto je najbolje vecina stohasticnih sustava se vrlo dobro da opisati i a njihov rad predvidjeti

pravi random sustavi su vrlo vrlo rijetki, rekao bih gotovo zanemarivi


ne kuzim kakvi su to spasioci kad enterpise SSD diskovi 2-3 puta manjeg kapaciteta kostaju 2-3 puta vise

Osim sto po definiciji "stohasticno" znaci "random".

To sto se daju matematicki (vjerojatnosno) modelirati ne znaci da se daju dobro predvidjeti.

U tom slucaju, ti mora da si izuzetno bogat covjek ako si, primjerice, navalio na burzu, imajuci u vidu tvoju gornju hipotezu...

Kako je vec Bubba rekao, stohasticno = random = slucajno. Cim je nesto slucajno, ne moze se modelirati na nacin da mozes predvidjeti tocnu vrijednost, sto znaci da u tom slucaju cache nema previse smisla (osim ako cache-hit radio od 20% ne smatras uspjehom). :kafa:

Primjer jednog tipicnog random sustava ti je transakcijska baza podataka (OLTP aplikacije). Ako ti mozes predvidjeti 80% od 100k IO operacija koje se zele obaviti svake sekunde, ja te ovog trenutka vodim na rucak. Daj mi takav algoritam slozi, jer mi treba za neke druge puno pametnije stvari. ;)

Inace, enterprise SSD diskovi kostaju za isti kapacitet po 10-20x vise od obicnog FC diska na 15k (400GB SSD vs 450GB FC). No, kazem, spasioci jer za potrebe aplikacije koja mora imati diskovni sustav sposoban isporuciti 20k IOPSa ne trebas 100 komada 15k FC diskova koje ces short-strokeati, vec 4 SSD diska. Racunaj da ove FC diskove treba sloziti u ladice ($$), treba ih napajati energijom ($$), treba ih ohladiti ($$), treba dimenzionirati UPS i za njih ($$), treba imati minimalno jos 2-3 hotspare diska na 100 komada ($$), i kada sve $$ zajedno zbrojis zajedno sa 100x cijenom FC diska, dobijes zanimljivu brojku koja ti kaze da ti je ipak dugorocno isplativije koristiti SSD disk nego te silne FC diskove.

Mnogi se zafrknu kada racunaju samo CapEx (kapitalna investicija, odn., ona prvotna - kupnja diskova), a ne racunaju OpEx (operativna investicija, odn., lova koju trosis za odrzavanje takvog sustava).

Svaki sustav dimenzioniraš prema potrebama i zahtjevima baziranima na mikroanalizama. Nije isto dimenzionirati billing bazu i backup sustav. Zato se i najčešće nalaze heterogeni sustavi i svako logičko polje konfigurira samo za sebe.
Stvar je potpuno identična. Samo su sustavi za banke "malo" jači (i to često ne uvijek, mnogi sustavi za "profesionalce" su bitno jači od onih u mnogim bankama).
Ni najmanje. Enterprise sustavi su čak po tom pitanju jednostavniji nego kad se radi o midrangeu. Da ne govorim da je i najjače opterećene diskove moguće potpuno iskoristiti ako znaš što radiš. :D
Takve sustave sam samo ja instalirao desetine i to nekad skoro na tjednoj bazi, a ljudi koji se time bave imaš kod nas na desetine. SAS/SCSI je jeftin standard, FC je taj koji je (relativno) skup, ali danas sve prihvatljiviji i poduzećima u nižem srednjem segmentu.
Nema ti tu pobjeda i poraza. :D

Ne, nije tocno ovo sto govoris. Random znaci da je vjerojatnost jednako distribuirana izmedju svih mogucih dogadjaja. Stohasticki znaci da su dogadjaji samo odredjeni vjerojatnosću ne i kakvom. Dakle ako to gledas random dogadjaji su podskup stohastickih dogadjaja.

Npr dogadjaji na burzi su puno neodredjeniji stohasticki procesi od npr racunalnih procesa. Dalje ako pogledas malo povijest burzi lako mozes zakljuciti da ako sad ulozis u neki portfelj za 20 godina sa 99% sigurnoscu mozes racunati na rast vrijednosti istog ;) Nije to bas tako "random" kao output nekog pravog random generatora ;)

Da ne kompliciramo - ne mozes deterministicki odrediti kako ce se ponasati OLTP sustav, osim da ce pristup podacima biti izrazito random i da od cachea nema tu puno pomoci (osim ako raspolazes sa parsto GB cachea). :hitthewal:

lol ovo bi trebalo repostati na hsgr :D

deterministicki odrediti ponasanje OLTP sustava je dobar naslov teme za tvoj sljedeci unos na blogu

Pa da, tako da mi nije jasno zasto se ti lovis za najgore slucajeve i neke ekstremne redove velicina.

Svasta je moguce ali se to ne radi osim ako netko ne pritisce.

Nisam znao da je FC prihtavljiv u nizem srednjem segmentu i da se sustavi za baze reda velicine par TB instaliraju na tjednoj bazi u Hr...


Nekako se uspjelo desiti da imam dva svoja identicna replya zaredom :)

Pa dao sam primjere i za jedno i za drugo. Isto tako, primjetan je rast kvazi OLTP prometa (iliti, jako random iz perspektive diska) primjenom virtualizacije, što sam problem jako potencira.

Ne mora uopće biti neki pritisak. Ukoliko imaš neku bazu koja je aktivna, recimo, od 7 do 21 sat, ostatak vremena ti isti diskovi većinu svog prostora mogu koristiti za backup, primjerice. Zato su analize stanja jako bitne i moraju biti i detaljne i dugotrajne.

FC postaje prihvatljiv (posebno kad je virtualizacija u pitanju, DR i slično), a i takvi sustavi se stvarno instaliraju stalno. Ja sam nedavno imao period od 6 - 7 tjedana gdje sam samo išao od korisnika do korisnika i instaliravao ih.

Ne znam cemu ismijavanje mog bloga. Ima tamo zanimljivih stvari koje su se tek nedavno pojavile, ili jos uvijek nisu. Isto tako ima u mojoj bazi stvari koje se nece pojaviti jos dugo vremena, no te ne idu na blog.

Sto se tice slucajeva o kojima pricamo, OLTP je samo bio primjer tipicne okoline kojoj ne mozes odrediti deterministicko ponasanje. No, ovo je sada vec poprilicno odlutalo od teme i samo se bezveze prepucavamo. Iggy ti je spomenuo jos i virtualizaciju (o kojoj, srecom, poprilicno i osobno znam), tako da je to jos jedan primjer za okolinu cije ponasanje ne mozes predvidjeti, stoga kakav god cache imao, koristi ga radije kao write-cache, nego kao read-cache. Ili, ako imas sustav koji je sposoban dinamicki alocirati i balansirati izmedju read/write cachea, mozes za dnevne produkcijske potrebe koristiti 10 READ - 90 WRITE, a u nocnom radu (dnevni inkrementalni backup, i slicne Tier2 aplikacije) stavi 90 READ i 10 WRITE.

BTW., Iggy, jel ima kakav sustav koji moze tako dinamicki alocirati cache, ovisno o potrebama? Znam da ovi napredniji imaju cache partitioning, no to mi samo sluzi da definiram cache-page (4k, 8k, 16k, itd) za potrebe nekih specificnih aplikacija (SQL, Exchange, Oracle, DB2, itd). Mene bas zanima da li ima nacin kako dinamicki alocirati ovo sto sam gore napisao, nikad to nisam vidio niti na jednom storage sustavu.

Sto se tice FC-a, istina je da je tehnologija postala prihvatljiva i manjim korisnicima (SMB market) i da se sve cesce korisnici odlucuju za takve sustave. A sto se tice onog da se dnevno instaliralo par komada, nije bas dnevno, ali recimo u periodima od 2-3 tjedna bi otisao jedan takav sustav ili bi se nadogradjivao postojeci.

Ma daj?

Nabavi neku knjigu uvoda u teoriju vjerojatnosti i hrvatski rijecnik.

Stohasticki = slucajno = "random"

Stohasticki procesi = slucajni procesi = "random process"

Mozes mi jos jednom definirati "random dogadjaje" (i prevesti to na 'rvacki) i "stohasticke (?) dogadjaje"?

Aha, ipak vidim da osim sto kuburis s teorijom vjerojatnosti i hrvatskim, ipak nisi bogati burzovni mesetar...

Elementarno, zelis li pokazati primjer stohastickog procesa X = (Xn, n>0) takvog da je Xn integrabilan za svako n > 0, ocekivanje Xn = X0 i da X nije martingal s obzirom na prirodnu filtraciju, najjednostavnije je uzeti niz nezavisnih jednako distribuiranih slucajnih varijabli za koje postoji konstantno ocekivanje. Hmmm, kada pogledam ovo tvoje...

...ajde ti to nama jos malo jednom izdefiniraj, pa da mi svi budemo pametniji, sretniji i zadovoljniji...

E, Bubba, sad si ga vala ubio sve u pojam.

Ajde dosta detaljiziranja, necemo se pravit pametni vise. Aj giv ap. :)

Ne. Slucajno moze biti definirano kao jednakomerna raspodjela vjerojatnosti ali i kao neka druga.


Dogadjaji mogu imati random (jednakomjerno rasporedjenu) vjerojanost sto znaci da ako imas n mogucih dogadjaja, njihova pojedinacna vjerojatnost limitira u 1/n. Stohastički proces tj njegovi dogadjaji mogu biti jednako vjerojatni (random) ili raspodjela vjerojatnosti moze biti po nekoj od funkcija (gaussova itd).

Biti bogat burzovni mesetar ima jako malo povezanosti sa ikakvim teorijama.

A sto sam ja napisao, a ti prepisao iz knjige? :lol2:

Sad ako je ovaj stvarno matematicar znaci da valjda razumije ovo o cemu se pise ovdje ali onda definitivno ne razumije hrvatski...

On nije FERovac, on je doslovno matematicar. Nemojte se sad navlacit sa matikom na ovoj temi gdje smo se tako lijepo poceli pricati o diskovnim sustavima. :)

Bubba, ne svojataj temu! :chears:

Vidim u cem je nastao problem. Ima i pravo sto se tice terminologije :)

Ja sam konkretno mislio na raspodjele vjerojatnosti kod nekog stohastickog (random) procesa - koliko sam ja razumio Iggy je tvrdio da je ta raspodjela jednakomjerna unutar tih random procesa - to je meni znacio pojam "random" koji on koristi - i da caching zbog toga nema smisla - jer u tom slucaju i nema smisla. Cim ta raspodjela nije jednakomjerna nego npr Gaussova ili bilo koja u kojoj jedni dogadjaji imaju pa cak i minimalno vecu vjerojatnost caching ima smisla i ovisno o toj razlici se moze manje ili vise iskoristiti.

Ja cu govoriti u svoje ime, ali mislim da i Iggy jednako razmislja.

Slucajnosti o kojima mi pisemo, pogotovo jer pricamo o realnim aplikacijama, su takve da ih je nemoguce determinirati (dakle, odrediti). Meni na storageu sa 1TB cachea nista ne znaci read-cache ako imam 2000 diskova sa zadnje strane. Jednostavno, napadi na produkcijske okoline ciji podaci se drze na takvom storage sustavu su nepredvidivi i ne postoji taj read-cache algoritam koji ce znati odrediti koji ce biti sljedeci podatak koji ce biti procitan, ili barem blok podataka. U tom slucaju mi puno vise znaci da imam veliki write-cache i izrazito velik throughput na diskovima. A SSD diskovi mi omogucavaju bas to - izrazito velik throughput.

Racunaj da 15k FC disk ima throughput u nekakvim standardnim uvjetima koji iznosi oko 180 IOPSa, a jedan SSD disk moze imati od 2000 pa do 30000 IOPSa.

Svojedobno sam vodio slicnu raspravu sa kolegom iz bivse firme u kojoj je on uporno tvrdio da na storage treba staviti cijeli veci dio cache memorije u read-cache, a ja se - eto - nisam mogao nacuditi otkud njemu takve ideje. :no2drug:

Da zakljucimo - SSD diskovi imaju svoju primjenu (i itekako su opravdani u nekim sustavima, iako im je cijena iznimno visoka). FC diskovi sa druge strane postaju commodity i sve se cesce mogu vidjeti u manjim okruzenjima. Izbor diskova (kapacitet i kolicina) ovisi o primjeni i jedino sto je bitno je dobro dimenzioniranje sustava. A opet, dimenzioniranje ti ne moze napraviti netko tko se ne kuzi u to sto se trazi. I na kraju, onaj najbitniji dio (koji je i uvijek najbitniji) - proizvodjac sustava je nebitan, dok god se business moze vrtiti na takvom sustavu kontinuirano i bez prekida. :chears:

Dakle imas mjerenja koja potvrdjuju da je raspodjela citanja sektora takva da svaki sektor ima jednaku vjerojatnost da bude procitan u sljedecem requestu? Ako imas molio bih te da ga linkas, bas me zanima.

Jos jedno pitanje - sto ti mislis zasto uopce postoji na racunalima memorijska hijerarhija odnosno cache?

Cek, nisam te bas shvatio. Otkud tebi ta tvrdnja o jednakoj raspodjeli citanja sektora, ja ju nisam niti u jednom trenutku rekao, niti sam insinuirao na istu. Ne mogu bas povezati sa nicime sto sam rekao, a da bih ti mogao smisleno odgovoriti. Ajde pojasni malo sto si mislio pitati?

Inace, kako sam vec ranije napomenuo - sve ovisi o primjeni.

Ako imas allaround sustav (recimo tipicni PC), onda imas vise tipova memorije - tvrdi disk, disk cache, RAM, L2 cache, L1 cache. No ovdje je puno lakse odrediti koji podaci ce biti procitani u sljedecem IO ciklusu jer je sve tu visemanje slijedno citanje.

Ako pak imas nekakav audio/video sustav (recimo nekakav video-on-demand sustav), tu mozes komotno veci dio cachea baciti u read-cache jer ce sustav 80% vremena raditi u modu sekvencijalnog citanja i onda nije nikakva mudrost odrediti koji ce biti sljedeci procitani podatak. E, da, iTunes je pak sa druge strane puno zeznutiji sustav koji bi granicio sa OLTP sustavima po svojim karakteristikama, no ovaj bi imao kombinaciju OLTP-a i sekvencijalnog citanja, tako da ces imati velike koristi od read-cachea.

Ali ako imas izrazito stohastican sustav (reci ti meni, jel tebe ovo zivcira ili zabavlja ili samo trollas bezveze?), po tvom - sustav u kojem svaki podatak ima podjednaku vjerojatnost da ce biti sljedeci, sto na velikoj kolicini podataka cini bilokakvo predvidjanje besmislenim, tada je takvom sustavu read-cache doslovno beskoristan. Jedino u slucaju da cache-hit ratio od 0.002% smatras velikim uspjehom. No, vjerojatno postoji ista sansa da ce se meni ispuhati guma od auta preko noci. Nije nevjerojatno, ali je vjerojatnost toliko mala da ce se to desiti da se uopce ne isplati zafrkavati sa time.

Inace, ako te bas zanima, ovi malo veci enterprise sustavi koji imaju brda i brda cachea (>128GB) taj cache koriste vecim dijelom za write-cache, jednim velikim dijelom za cache koji se koristi kod replikacije (sinkrone ili asinkrone) ili izrade klonova/snapshota, i jako malim dijelom za cisti read-cache.

Replikacija - to ti je zapravo repliciranje write-cachea izmedju dva storagea.

Izrada klonova - e, za ovo ti recimo treba read-cache, no to nije nimalo random okolina, vec imas cisto slijedno citanje, tako da imas nesto i za predvidjeti da ti sansa bude veca od 50% da ces pogoditi sljedeci podatak. Izrada snapshota se svodi na random write, i nema bas neke veze sa read operacijama.

Kod random procesa ne mora biti nikakve ravnomjerne raspodjele, bez obzira da li bile kuglice u loto bubnju ili sektori po diskovima. :D

Sumnjam da ćeš naletiti na takvo što. Niti ima smisla.

Iggy, nisi mi odgovorio.

Jel ima nekakav storage sustav koji je u stanju dinamicki balansirati read/write cache ovisno o nekim predefiniranim parametrima (dnevni rad/nocni rad). Ili su svi napravljeni tako da budu set&forget?

Sjeca se kada smo nas dvoje pricali o ekspertnom sustavu koji bi dinamicki i inteligentno odredjivao korisnicke kvote? Ovo ne bi bilo daleko od toga, a ako Iggy kaze da toga bas i nema, mozda ne bi bilo lose nalupati kakav kod da se to napravi makar kao proof of concept...
Make me, cunt!
Mani se corave matematike. :)

Da, i zbog toga sto distribucija vjerojatnosti nije ravnomjerna caching ima smisla - dogadjaje sa vecom vjerojatnoscu pohranis u cacheu sa manjim vremenom pristupa i vecim brzinama prijenosa - voila stvar se ubrza.

Ne znam mozda cu morat pocet crtat :lol2:

Cijelo vrijeme i pricam o tome da takvo sto ne postoji i da cijela prica oko toga nema smisla - a cache i memorijska hijerarhija upravo zbog toga IMAJU smisla!

Calypso trebao si me odmah upozoriti da je ovo neki tvoj :lol2:

Kvragu, nisam ni vidio, na prethodnoj je stranici, a ne da mi se gledati. :D
Automatsko dinamičko balansiranje mislim da neki veći sustavi mogu (iako je upitna korist, da li želiš pokušati implementirati QoS u situacijama kad ti takvo što može na drugim razinama srušiti performanse, isto pitanje kao kod thin provisioninga), u midrangeu možeš putem skripti, kao što možeš i igrati se sa snapshotima, rekonfigurirati storage grupe i slično. Ako misliš, recimo primjer, mijenjati cache postavke kako bi oslobodio više memorije za noćni backup, moguće je.
Shvaćaš li ti razliku između "nema vjerojatnosti" i "veće vjerojatnosti"?
A mogao bi polako. :D
Ti trolaš ili ti fakat nije jasno?:stoopid:
Da, cache općenito ima smisla. Osim kad je nešto random. Tad je preporuka isključivanje read cachea na mnogim razinama.

Uffff kakve li rasprave :D

Da ne ostane sve na rijecima ... vjerojatno ste se vec susreli sa ZFS-om i Hybrid Storage Pool rjesenjima ... ali tek toliko da ozivimo malo temu :)

:D
Sad si ga zakuhao. :D
Da, ZFS i Hybrid SP su OK, ali imaju problemčić - cijena. :(
Naime, ako to probaš implementirati u ozbiljnijem okruženju, SSD se troše k'o ludi (moraš ići sa SLC), a tu su cijene... Uh. :(
Ima varijanta koja mi se više sviđa, asinhroni mirror. :D

Ma mamu im njihovu... Prije godinu dana sam predlagao nesto slicno EMCu... Sa jedne strane imas SSD, a sa druge strane imas nekoliko obicnih vrtilica-diskova u RAID0 polju, i radis asinkroni mirror... Pa sam dobio odgovor - to ti nema smisla...

Vec mi je lagano dosta tog odgovora "to ti nema smisla"... Kad sljedeci put cujem nesto slicno, odma idem razradjivati do detalja, jer ocito je da ima smisla... :)

@Iggy

Necu vise obecajem :D

BTW zanimljiv je taj asinkroni ... jednostavno i prekticno ... skoro kao write caching na kucnom racunalu (samo uz pokoji disk vise hehe).

Eh da sjetih se i jos jednog principa - MFT-a za flash diskovlje (korisno je u najmanju ruku za write caching) ... gotovo ih pretvara u RAM diskove, ali opet je cijena poveca ... ma joj, necu vise samo kuham u zadnje vrijeme :D

:D:D:D
Baš nemaš sreće. :D
Iz nekih razloga to je lakše implementirati na aplikacijskoj nego na samoj storage razini. :kafa:
:D
Petlja se poprilično u zadnje vrijeme s takvim idejama, no problem nastaje u tome što su ekstremni zahtjevi poprilično rijetki (kako radi IOPS-a, tako i radi latencija) pa je pitanje isplativosti takvih tehnologija na svim razinama.

http://en.wikipedia.org/wiki/List_of..._distributions

to si prouci, sve to spada pod "kad je nešto random"

http://en.wikipedia.org/wiki/Uniform...8continuous%29
:fiju:

Ovo ti nije trebalo... :nono:

Ja odustajem, pokazao si samo volju za pametovanjem i 'tjeranjem konca na mak', pa kud puklo da puklo. Nekolicina ljudi (neki i sa iskustvom od preko 10 godina u radu sa diskovnim sustavima) ti je lijepo dala primjere kada je potrebno iskljuciti read-cache, no ti i dalje tupis po svom i trazis, sada vec, nepostojece greske u koristenju izraza.

Inace, wikipedia ti i nije bas neki relevantni izvor informacija. :kafa:

Nti sveca, mene i Bubbu kao službeno matematičare ideš hranit' ovim? :stoopid:

Da, i koji se to racunalni sistem / proces ponasa i priblizno tako osim hardverskog generatora random brojeva?!

Jel ti stvarno nisi pratio sto smo pisali do sada ili ne znas citati ili ne razumijes hrvatski?

OLTP ti je tipican primjer takvog sustava. OLTP aka. On-Line Transaction Processing. Dakle, procesiranje potpuno random upita u realnom vremenu.

Ako znas za neki prefecth algoritam kojim bi bio u stanju predvidjeti fizicke lokacije podataka koje dohvaca mreza od 500 (ma i 50 je dovoljan broj) bankomata i da ti je konacni rezultat veci od 20%, molio bih te da mi ukazes koji je to algoritam jer cu ga moci skupo naplatiti korisnicima.

I nemoj mi samo poceti o hijerarhijskim strukturama memorije jer ova realna primjena koju sam ti opisao je cista dzungla, a ne uredjeni sustav jednog racunala na kojem radi jedan korisnik. Ovdje trebamo raw power, a ne inteligentne algoritme.

Inace, jedno pitanjce ovako sa strane - sto mislis, cemu tocno sluzi mainframe i zasto se jos uvijek jako dobro prodaje?

Ovo prvo je posljedica ovog drugog, ocito.

Brdo njih, primarno velike baze. Tebe stvarno tu muči, a?

Da, volio bih vidjeti neki dokaz / rad koji tako nešto potvrđuje jer do sada to još nisam vidio. I dalje stojim iza toga da ponašanje bilo kakve poslovne aplikacije / oltpa nema uniformnu podjelu vjerojatnosti i da kod takvih sustava cache ima itekakvog smisla.

Prefetch čak i ne spada u klasični caching. Ja nisam tvrdio da se sa cacheom moze nadomjestiti neki fizicki resurs, nego samo da cache znacajno pomaze u vecini slucajeva. Takodjer u ovom primjeru ne kuzim zasto npr algoritam ne bi pratio ucestalost koristenja pojedinog accounta i one koji se cesce koriste drzao u nekoj brzoj memoriji, u cacheu? Na kraju, same baze podataka su napravljene tako da vrlo dobro iskoristavaju svu mogucu memoriju za caching.


Ja imam jedan savjet za tebe - prouči arhitekturu mainframeova.

MOD: Ne postati dva puta zaredom! Koristiti multi-quote i sve 5.

Prvo, ne bi ga držao zato jer ima premalo cachea za takvo što, drugo, govorimo o diskovnim sustavima, ne poslužitelju s OS-om i aplikacijom (gdje jedino aplikacija može ponekad definirati što je češće a što rjeđe, ne diskovni sustav i kontroleri / cache do njega).
Ako misliš da bi neki ekspertni sustav mogao to raditi, mogao bi, ali s dva uvjeta: ogromna količina memorije za cache i višak procesorske snage.
Ja je detaljnije poznajem, na što točno misliš? K tome, detaljnije poznajem i arhitekturu transakcijskih sustava (koji su idealan primjer za ovaj thread).

Prefetch je princip rada bilo kojeg caching algoritma. Ja stvarno ko da sa zidom pricam. :hitthewal:

Idemo dalje, iz svega navedenog i ovdje prikazanog je ocito da ne poznajes internu strukturu diskovnih sustava, vjerojatno niti diskova kao takvih. To sto si gore naveo pod 'ne kuzim zasto npr. algoritam ne bi pratio ucestalost koristenja pojedinog accounta i one koji se cesce koriste drzao u nekoj brzoj memoriji' je recimo jedan od nacina kako caching i radi. Ali tebi nikako da dodje do glave da u velikoj vecini primjena takav princip rada NEMA SMISLA.

To sto ti ne vjerujes da je raspodjela vjerojatnosti uniformna je tvoj problem, mi koji se time bavimo znamo jako dobro koji je to problem, zbog cega je prisutan, kako se manifestira i na koji nacin se rjesava. Jedino ti, koji si doslovno pao iz vedra neba, tvrdis da to sto mi kazemo nije istina. Rekao sam ti - imaj si korisnika, radi na svoj nacin i prati njegovo zadovoljstvo radom, to ti je najbolji nacin kako da ocijenis da li nesto funkcionira ili ne i da li ti je pretpostavka bila dobra.

Inace, ti mozes cijeli LUN prebacit u cache ako te to zadovoljava, imas na EMC Symmetrixu nesto sto se zove PermaCache koja je u stanju uzeti LUN i iskopirati ga u cache memoriju. No, Symmetrix ima mogucnost prosirenja cache memorije na preko 1TB, a o cijenama necemo. Sa druge strane, imas tehnologije koje se bave automatskim storage tieringom i u stanju su automatski i bez gledanja korisnika seljakati ili LUNove ili blokove podataka prema performansnim zahtjevima. Recimo, primjera radi - imas 3 tipa diska u staroge sustavu - SSD, 15k FC i SATA. Imas nekoliko tipova aplikacija koje rade i koje nemaju sve iste performansne zahtjeve. Tehnologija koja je zaduzena za automatski tiering gleda statistiku koristenja sustava unatrag nekoliko dana/tjedana i nanjusi koje kriticne podatke moze pobacati na brze diskove, koje moze na sporije diskove, a koje nema potrebe dirati i seljakati okolo.

Sto se tice mainframea, nemas brige tu, znam sasvim dovoljno o tome, no cudi me da nisi shvatio poantu zasto sam te to pitao. Dakle jos jednom, koja je primarna namjena mainframe racunala i gdje se oni zapravo koriste i pokazuju svoju pravu moc? A usput, mozes mi dati i primjere nekoliko modela ako ti se da istrazivat, tek toliko da vidim da pricamo o istoj stvari. Vise ti nis ne vjerujem, previse gluposti si napricao i uporno se pravis pametan.

Samo sam htio naglasiti da kod bazi od par TB disk nije jedini element sustava i da sve skupa treba gledati kao cjelinu, a ne davati nekakve ocjene da nešto treba kad u većini slučajeva ne treba.


Konkretno mislim da je sistem usklađen u smislu idealnog opterećenja svakog resursa (i dovoljnog broja istih) prema potrebama onoga što se izvodi na sistemu.

Također ako poznaješ transakcijske sustave onda ti je vjerojatno i poznato da je nemoguće da događaji unutar transakcijskog sustava imaju uniformnu distribuciju vjerojatnosti. Samo u slučaju da resursa nema dovoljno može se reći da se cijeli sistem ponaša kao da je ta distribucija uniformna i tada samo cache i sve ostale stvari gube smisao - ali i u tom slučaju bolji IO sustav ne pomaže previše osim ako samo on nije bottleneck cijelog sistema. Eto, samo to.

Ti ko da radis u jednoj banci tu kod nas... :)

Sto se samog mainframea tice, imas nekoliko karakteristika:
1) Svaki proces se izvodi u minimalno dvije instance i rezultati se usporedjuju
2) Sve komponente su redundantne (procesori, memorije, sabirnice, itd)
3) Mainframe je masina namijenjena skoro pa iskljucivo transakcijskom okruzenju, to nije procesorski mocna masina, ali po IO operacijama joj nijedna druga mnogostruko procesorski mocnija platforma ne moze ni primirisati

Zato sam te i pitao jel znas cemu tocno sluze mainframe masine i zasto se i dan danas prodaju.

Sto se bottlenecka tice, diskovni podsustav je uvijek bottleneck svakog sustava. U nekim sustavima vise, u drugima manje. Postoji i opcija da je aplikacija lose pisana, ali aplikacija se moze izvaditi na dobro poslozenom diskovnom podsustavu, dok se i najbolje pisana aplikacija moze itekako vuci na lose postavljenom diskovnom podsustavu... Razgranici pojmove sustav i podsustav, pricam opcenito u ovom slucaju.

BTW., oces primjer jednog hebeno random (uniformno random) okruzenja? SMS centar za recimo nekog mobilnog operatera u Kini ili Indiji. Ako si ti u stanju predvidjeti tko ce kome slati SMSove, kada i sto ce tamo sve pisati, onda ozbiljno skidam kapu... :chears: