Helios Green aneb nejsprasenejsi aplikace kterou znam

[Petrik]

2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

Hm, vsadim se, ze kdyz se zbavite toho SANu a nahradite ho jednim, nebo nejlepe nekolika X25-E/M s dobrym HW RAIDem R10, tak se vykon zmnohonasobi, tedy za predpokladu ze se neco z tech disku vubec taha. SAN ma totiz jeden problem a tim jsou latence. Porovnej latence FC (tedy neco ala ethernet) vs. lokalni SATA/SAS disk/SSD. Navic tech 15k disku vpoli muzes mit treba milion, ale latence budou porad radove horsi nez u jedineho SSD. V jedne firme jsem udelal obyc server s raptorem a 16GB RAM a oracle na tom behal rychleji nez na nejakym brutalnim IBM POWER serveru a to jen kvuli tomu, ze tam bylo nejaky hyper mega ultra SAN pole (celkem za miliony), ktery bylo desne pomaly...

SAN ma podle me smysl u clusteru, kdy to bez nej nejde (jde, viz google ), ale pro jeden server existuji lepsi vecicky a vyrabi je napr. firma Fusion-iO

http://www.fusionio.com/products/iodriveduo/ tahle hracka uz asi neco zvladne

NAND Type Single Level Cell (SLC) Multi Level Cell (MLC)
Write Bandwidth 1.4GB/s (32K packet size) 1.0GB/s (32K packet size)
Read Bandwidth 1.5GB/s (32K packet size) 1.4GB/s (32K packet size)
IOPS* 185,022(4K read packet size)
129,699(75/25 r/w mix 4K packet size) 122,601(4K read packet size)
121,008(75/25 r/w mix 4K packet size)
Access Latency <50µs Read <80µs Read

Mimochodem tohle DUO ma dvojnasobne latence nez "single", ktery ma 26µs, coz je proste mazec. To uz ma bliz k RAMce, nez k diskum.

Dalsi vec je pocet jader a skalovani vykonu. Nezapomenu, jak jsem do onoho obyc serveru s oraclem dal misto 3GHz dualcore 2.9GHz quadcore a vykon sel kam? vykon sel do kytek (4x pomalejsi), protoze vsemocny buh Oracle zvolil nejaky suboptimalni algoritmus nebo co a pomohla az nova verze Oracle serveru... jen mimochodem v te dobe jsem o SQL nemel ani paru, ten Oracle resil jeden dost zkuseny DBA..

Netusim jak je na tom MS SQL vs. skalovani vs. multithreading, ale napr. vim, ze MySQL pro jedno spojeni pouziva jen jedno vlakno, takze jader muzu mit treba deset a je mi to prd platny (proto ho provozuju na OC dualcore).

[Jezevec]

Tak na tom SANu neni jen SQL samo a vzhledem k velikosti databaze vs velikost dat/indexu se to vpohode vejde prakticky cely do RAMky, ty disky i podle stats vicemene jen zapisujou, cteni je naprosty minimum. Jak sem psal, zatezuje to CPU. A to "by woko" 3x vic nez "zastarala" PB verze. Je proste videt, ze nekdo optimalizoval az zoptimalizoval a zakaznici at se poserou. Druha vec je, ze paac M$, se neda rict, estli dalsi CPU pomuze nebo ne. M$ je na tom obecne tragicky a navic se to jejich SQLko chova tak kokotsky, ze kdyz jedinej user posle "pekny" query, tak sezere vsechny CPU a neprihlasis se ani na konzoli ....

2wong: mati je mzdovka, pocita tusim neco kolem 150 vejplat a vypocet trva mozna minuty na obyc PC, ale dyl IMO ne (schvalne se poptam).

[Petrik]

Ze to bezi na MS samozrejme ani nekomentuju, to je kapitola sama pro sebe...

Na co bych se zameril je tuning nastaveni toho SQL serveru. Vubec netusim, zda jde vubec neco nastavovat, MS SQL jse nevidel ani z vlaku, ale vim, ze napr. dobra vs. spatna konfigurace MySQL muze znamena RADOVY rozdil ve vykonu (klidne i nekolik radu). Zasadni vec je napr. mit pokud mozno temporary tables v RAMce, zamezit double-bufferingu FS OS+SQL a pod.

Jestli tam ale ti autori provadeji JOIN pres VARCHAR, tak je zcela evidentni, ze to jsou naprosti SQL amateri a lemplove a v tom pripade pomuze leda tak zazrak... takze uprimnou soustrast a dobrou noc.

[pajkus]

zkusim upozornit na tenhle thread, treba se to dostane az k zodpovednym mistum, nechce se mi verit ze by s tim nikdo zamerne nic nedelal...

[Jezevec]

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

[Petrik]

Tak pro zajimavost, spocitat vejplaty pro 70lidi cca 2 minuty na obyc kancl PC.

2pajkus: Ono by se to muselo cely vzit, zahodit a zacit od nuly, nic jinyho stim delat prakticky nejde.

me je naprosto jasny, jak to vyvijeli. Zacali s hodne spatnym navrhem databaze a pak na to zacali nabalovat nove anove funkce, az z toho vznikl dnesni stav. PRESNE totez se totiz stalo v te firme kde ted pracuji. Nejdriv zacinali jen s pomoci csv souboru (!!), pak nasadili databazi a jelikoz tomu nukdo nerozumel, pouzivali to stejne jako ty csv soubory. Ted je na tom naprosto tragickem navrhu desitek databazi postaven cely system, tedy desitky a stovky tisic radku SQL a java kodu a nejde s tim nic delat nic jineho, nez kupovat silnejsi HW
Alespon tu neprovadime JOIN pres VARCHAR, zato databaze jsou casto sirsi nez vyssi (vic sloupcu (bezne 100 az 200) nez radek)

[Jezevec]

Tak co se tohodle tyce, oni prave relativne nedavno (4 roky) presli na .NET. A misto aby ten prechod vyuzili k predelani databaze a aplikace, tak proste cpy&paste pouzili to co meli => funguje to jeste hur nez predtim.

[Audun]

Zdravím, dlouho se tu nic nedělo na toto téma. Systém Helios Green se mohl za tu dobu někam posunout. Jaké máte i po těch letech zkušenosti s tímto systémem?

[Marty]

Co bys chtěl tak plusmínus vědět?