Helios Green aneb nejsprasenejsi aplikace kterou znam

[Jezevec]

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Ad vykon, 50lidi zaroven, nedelajicich prakticky nic jinyho nez vytvareni dokladu (objednavky, vydej, prijem ...) sezere 2x4 na procesoru SQLka na 100%. To myslim celkem slusne vypovida o uzasnem navrhu databaze. Nacteni prehledu dokladu pak trva v nekteryh pripadech i 30+s, insert do DB i minutu a vic. Tzv "tenky" klient sezere vpohode dvoujadro na 100%. Zato tzv "aplikacni" server nedela nic (ale pro jistotu se kazdou noc restartuje IIS).

Co se bezpecnosti tejce, proste se spoleha na to, ze uzivatel je dement, kterej nikam nepoleze.

[peta303]

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

[Geeker]

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

bajecny STAG zavadeli pred 6 lety ve Zline na UTB. Chyby systemu se omlouvali vyvojem a testovanim. Ja 4 roky po promocich jsem se opet setkal s timto "super systemem" a opet stejne chyby. Takze alespon na UTB se nic nezmenilo.

[Jezevec]

A mame tu dalsi pokracovani serialu . Viz vyse zminovane indexy. Dodavatel se(presne dle ocekavani) ohani tim, ze tam mame svoje indexy a ze je to pomale kvuli nim(inserty samo). Ale kdyz tam ty indexy nebyly, bylo to jeste 100x pomalejsi(na vsem ostatnim, protoze selecty) . Minuly tyden se samozrejme jedna nejmenovana odbornice pres databaze (select je pro ni sprosty slovo) vyjadrovala v tom smyslu, ze indexy nicemu nevadej a na namitky, ze to zpomaluje inserty rekla "ale jenom trochu". Mno ono u 120GB databaze to bude asi "trochu vic" .

Jinak celkem standard. Sefko dodavatele se svoji ekypou nasliboval, jak vsechno do dnes vyresi a dnes se po 15:00 ozval nakej jejich mamlas a ptal se, co ze to vlastne ma resit a plkal, ze sme nerekli co konkretne je pomaly (trace z databaze s odchycenymi 30s query mu je zrejme malo). Je uplne jedno s kym od nich se budeta bavit, pokud je to obchodak/managor, naslibuje vsechno. Pokud je to kdokoli jinej, posle vas doprdele. Jediny co uz od minulyho tejdne resej je, kde najit duvod nefunkcnosti na nasi strane (pro sychr mame HW dimenzovanej min 10x vejs, nez byly jejich pozadavky pro danej pocet useru). Navic pres nekolikere upozorneni ze se bude testit vykon systemu si nerekli co kde mame pozapinat a ted se ohanej tim, ze nemaj logy.

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

[Petrik]

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

Se spatnym navrhem databaze se moc delat neda....leda pridat vic RAMky a pouzit SSD, pripadne nejak hodne dobre udelat indexy + vytunit SQL server (pokud to jde). Ale nekdy to proste uz lip udelat nejde a pak se stane, ze jeden join zabere 6 hodin a clovek s tim proste nic nenadela .8GB RAM+ SSD + MySQL a brzdou je 4GHz CPU core-i3. Ten join pres VARCHAR me ale pobavil

[wong]

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Nejsme uz dcera CEZu a zamestnancu je cca 1500. Kdyz se pocitaji vyplaty, tak je system naprosto nepouzitelnej a neda se s nim normalne delat.

[Jezevec]

2wong: kdyz sme byli na navsteve (uz to bude tak 2 roky), tak nam tvrdili, ze vejplaty pocitaj 3 dny v kuse . Jinak ze si sem tam nekdo vyrobi objednavku na dily.
2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

[wong]

Jezevec: ano tak nejak to je, proto jsem opravoval pocet zamestnancu...

[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...

[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?