HW nároky malých aplikací

[j]

U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache.

A v čem je problém, když se nepotřebná RAM využije na keš?

Zeby v tom, ze z pohledu pripadnyho virtualu je to RAM pouzita, a tudiz ji nemuze pridelit dalsimu stroji, kterej by v ni trebas mel i neco uzitecnyho?

...
Nejčastější odpověď bude něco jako:
"eeee... hmmmm... noooo... víte, záloha se dělá ve 2 ráno, to tam stejně nikdo nebude, takže je to v pohodě"
případně rovnou
"eeeee cože?"

... co je to zalohovani?

Co používáš za virtualizaci? LXC i OpenVZ sdílí diskouvou cache mezi kontajnery, takže tvůj výpočet neplatí.

Pokud mas realnej skutecnej virtual tak asi tezko.

[Reklama]

[lopata]

Pokud mas realnej skutecnej virtual tak asi tezko.

To už je tvoje volba, co použiješ. Aplikaci je jedno, jestli běží ve full virtualizaci nebo v operating system level virtualizaci.

[tnr]

S čím mám problém? No s CPU ani ne, tam je mi to jedno, když to není vytížený. U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache. Ono se říká, že paměť je levná, ale:
- 128GB moduly opravdu levný nejsou
- fyzický stroj má omezený maximální množství paměti
- jeden fyzický stroj stojí jak hodně pěkný auto, špička už se blíží cenou k bytu až baráku
- každý fyzický stroj jsou desítky tisíc jen na energiích za rok, další energie jde na klimu, je potřeba mít dostatečně dimenzovaný záložní napájení atd

Ono se to může zdát jako sranda, ale provozovat spoustu flákajících se strojů, kterým stojí procesory a mají narvaný RAMky z velké části zbytečnou cache, to už taková sranda není.

A pronájem? No naštěstí ne každej je takovej čmoudofil a ne každej chce mít svoje data poházený kdoví kde.

Ono nejde o to, že je jeden takovejhle naddimenzovanej virtuál. Ono jde o to, že to je dneska zcela běžný požadavek každé firmy na jakoukoliv kravinu. A když už je ten požadavek na podobný kraviny několikátý jen za letošní rok, tak už začínám mít opravdu na podobný debility alergii.
Kdyby se raději ty zbytečný investice narvali do vzdělávání vývojářů, kteří by potom začali opravdu něco tvořit a ne jen malovat nenažranosti ve frejmvórcích, to by bylo krásně na světě, co?

Jasne, nebudeme pouzivat frameworky, nebudeme pouzivat high level jazyky, budeme to developovat 4-10x delsi cas, ale hlavne ze to pobezi na levnejsim HW, to se zcela jiste vyplati :-)

Ses proste zavrenej v svym sysadminovskym svete, vsichni ostatni jsou pro tebe idioti a podle toho to vypada Staci se podivat, jak se dneska tvori vetsina aplikaci - spoustu z nich se dela jako proof of concept, proste se to zkusi, dulezity je zejmena time to market, za pulroku z toho mozna bude uplne jina aplikace, nebo se to naopak cele zrusi, protoze se to neujalo. Doba waterfall tvorby software, kdy vse navrhnes od stolu, zoptimalizujes do nejmensiho detailu a pak to za 2 roky pustis ven, je davno a davno pryc, hlavne je to navic model, ktery je pro vetsinu firem zcela nepouzitelny.

Prave proto je pro spoustu firem dnes uzitecny pouzivat bud reseni ala cloudy, kde platis za spotrebovany vykon (tzn. nemusis resit zadne z techto problemu, co rikas - protoze memory/cpu zmenis okamzite, ci dokonce automaticky - vysoka dostupnost tez neni problem, pokud to bezi v vice regionech - cloudy sice vypadavaji [stejne jako vlastni HW], ale pri spravnem navrhu to neni problem osetrit), uplne stejne se to da resit v ramci privatnich cloudu. A nebo nejlepe pomoci kontejneru, kde se prostredky s minimem rezie daji krasne sdilet mezi jednotlivymi aplikacemi, to je osobne za me to nejlepsi reseni.

O tom, ze to, co mate, je spatne, neni moc treba diskutovat. Ale problem neni dle meho az tak v aplikaci, ale primarne v tom, jak to mate nastavene a vyresene s dodavateli, z cehoz plyne i takto totalne neefektivni vyuziti prostredku na fyzickem zeleze.

Ale na druhou stranu je faktem, ze s HW prostredky se plytva, protoze opravdu levne jsou vuci praci. Oni nejsou tak levne, pokud pouzijes waterfall model, vis presne na zacatku, co od te app chces, jak bude vypadat, jak se zoptimalizuje a ze se takto nezmenena bude pouzivat nekolik let. Ale takhle to typicky vubec neni. A kdyz se nad tim zamyslis, ze optimalizaci by ses dostal treba na nizsi naklady na HW v adekvatni hodnotu nekolik malo hodin vyvoje,tak se to opravdu nevyplati. Protoze ta aplikace se stejne bude menit, predelavat, takze bys optimalizoval vse do detailu porad a v dusledku to stalo 10x tolik. Samozrejme, nejake zakladni veci ma smysl resit vzdy (indexy, design db, pouziti vhodnych nastroju), ale diskuse nad tim, zda pouzivat nebo nepouzivat frameworky, aby usetrili nejaky treba 1 GB RAM [a to kdovi jestli], je uplne mimo.

[tnr]

To je právě jedna z těch tisíckráte opakovaných lží dneška. Ve skutečnosti to platí jen v určitých případech, ale nelze to zevšeobecňovat. Hlavně to není žádná lineární závislost. Jinými slovy - proč optimalizovat databázi, to je lidská, tedy drahá práce, když HW to zvládne i tak. Jenže v určitém momentu to překročí bod, kdy se najednou ukáže, že cena HW začíná vykazovat své exponenciální chování oproti lidské práci a že náprava celé té situace vyjde několikanásobně dráž, než kdyby se to bývalo udělalo pořádně hned na začátku.
To je pak podobná logika, jako nač věnovat pečlivost zakládání budovy. Dvě patra to unese a až budeme přistavovat páté, tak to třeba začneme řešit. Kdyby tak někdo spočítal, kolik tahle krátkozraká řešení, aby se ušetřilo, stála nakonec peněz navíc...

to je samozrejme castecne pravda. Ale na druhou stranu faktem je ten, ze cost vetsinu vychazi v neprospech lidske prace nez HW. Ono by to platilo, jak jsem psal, v pripade, ze by ta aplikace byla staticka, jednou se udelala a pak bezezmeny provozovala, tam ma smysl to jednou zoptimalizovat poradne (i kdyz, i to je otazka jak moc se to vyplati). Ale ono je rozdil to optimalizovat a delat blbe. Neudelat napr. alespon elementarne spravny navrh databaze, indexu, pouzit vhodne datove struktury a nastroje - pokud se nedela tohle, tak je to prote jen blbe, protoze to jsou ve vetsine pripadu veci, ktere nestoji zadnou praci navic.

Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.

[tnr]

Ani LXC ani OpenVZ nejsou plnohodnotná virtualizace. Používáme VMWare, protože je to jediná virtualizace jak s podporou pro hypervizor jako takový, tak od ostatního (komerčního) SW.

No, to je ale pak presne ta chyba, je potreba jednat s dodavateli a vybirat vhodne technologie. Jakoze, popravde, bez LXC/OpenVZ/Dockeru si opravdu zivot uz predstavit nedokazu, neskutecne to usnadnuje zivot a nasi praci, neni problem se sdilenim prostredku, neni problem s deploymentem, pripravou staging prostredi atd.

VMware samozrejme pouzivame taky, ale kontejnery nam bezi na nekolika malo VM, VMware nam nasledne zajistuje vrstvu nad tim.

[Reklama]

[Tuxik]

tnr: proof of concept bohužel znamená "zbastlíme to stejně jak finální aplikaci". Frameworky mají svoje místo, netvrdím, že se má pokaždé všechno znovu vymýšlet a stavět na zelené louce, ale je třeba to brát trochu inteligentně. Nemám to "vývojářům" (čti aplikačním malířům) za zlé, chyba je i na straně zákazníka, že dokáže na neskutečný prasečiny podepsat smlouvu.
Typický příklad:
Zákazník: chci statický web, asi 5 stránek, pár návštěv za den
Dodavatel: Fajn, uděláme to v XY, potřebujeme 8 jader, 16GB RAM, 2 měsíce, 2 mega
Z: a pak chci IS na míru, 100 uživatelů, cca 50 současných přístupů
D: Fajn, uděláme to v XY, potřebujeme 8 jader, 16GB RAM, 10 měsíců, 10 mega
Z: Aha... a to můžete něčím podložit, nebo si to cucáte z prstu?
D: Sme snad blbci, nebo co? Máme zkušenosti, jsme špička v oboru, tak jsme řekli, tak to bude.

Smutnou realitou je, že absolutní většina SW malířských firem nemá ani páru o tom co dělá. Opakovaně za jejich vývojáře řeším jejich problémy, který oni odmítají řešit s tím, že máme rozbitý a pomalý servery a v absolutní většině případů je problém na straně SW. Oblíbená fičura je SQL dotaz s 50 joinama a z toho aspoň 10 LIKE %kokotina%. Aháááá a to se jako nesmí? Vždyť to fungovalo... dokud nebylo moc dat... no tak přidáme indexy, neee? Na rootu jsem četl, že indexy to zrychlujou... WTF? My jsme špičkoví vývojáři a né ňácí pošahaní databázisti. Buďte rádi, že jsme to spíchli aspoň nějak.
Další oblíbenou fičurou je škálovatelnost... fajn, něco se rozrůst může až za nejbláznivější původní představy, ale co s tím? Joooo přihodíme jádra... aha, on ten výpočet jede jenom v single threadu... no tak rychlejší CPU... no vidíte, už to netrvá hodinu, ale jenom 3/4, měli jste to rozbitý...
A co teprve lahůdky typu totálně zasekanej server a přitom se CPU nudí a paměti je dost... takový wait for interrupt je pěkná svině... A co to je? A proč to je? Máte to rozbitý, nám to na našich testovacích datech (kterých je možná setina oproti ostrým) funguje skvěle.
A nějaký navazující věci? Zálohy? Monitoring? Kontroly konzistence? Heee? Ste spadli z jahody na znak? To nedělá nikdo.

Takže jinak. Profesionální práci si představuji takhle:
Aplikační jádro cca 2GB
Každý připojení si může spustit proces, kterej potřebuje 10-100 mega, průměrně to bývá kolem 30, maximum je při takové a takové operaci
Chcete to pro 50 současných přístupů? 2048+50*30 a doporučujeme přidat 30 procent rezervu na špičky + tolik a tolik pro OS.
Klidně začněte s tím, že bude 10 přístupů, přidat se dá vždycky. Ostatně, jako profesionálové máme v ceně projektu analýzu po 3, 6 a 12 měsících, po které vždy upravíme nastavení, přidáme indexy kde budou třeba a případně dáme další doporučení.

Líbí, nebo nelíbí? A jestli víš o někom, kdo je toho schopnej, tak sem s ním.

Co se týče výběru dodavatelů... jsou prostě věci, kde není moc z čeho vybírat a tam je potřeba se přizpůsobit. Jinak rozházet servery na několik různých virtualizací je dobrej nápad... kromě toho, že se musíš starat o víc systémů, tak chci třeba vědět, jak v případě potřeby přemigruješ bez výpadku virtuálku mezi OpenVZ, LXC, Dockerem, VMW... aha... to asi neklapne...

[j]

2Tuxik: Prakticky 100% adminu by vsechny ty appky napsalo 10x lip a 10x driv, nez tyhle "vyvojarsky spicky", jenze na to nemaj cas, protoze to po tech kretenech musej vsechno opravovat a udrzovat v chodu.

Pro zajimavost, eet ... konfigurace ... vydajovy doklad na ni sere ... podle vyjadreni tech idiotu je to vporadku, protoze je prece normalni ze neco sere na konfiguraci, protoze vydajovy doklady do eet ... vetsinou nespadaji.

O selectech do databaze ani nemluvim ... protoze pokud neco zrychlis o 5 radu, tak to rozhodne neni optimalizace dotazu, ale totalni imbecilita tvurce.

Nebo ... chces neco vytisknout ... no tak nekdy a nekde ti tisk nabidne ... F5, jindy a jinde F8, a jeste jinde treba ctrl+P ... podle toho, jakej debil zrovna tu kterou cast psal. Vse samo jedna aplikace.

A sranda nejvetsi ... dodavatel vznes pozadavky na HW ... poridili sme asi tak 100x vykonejsi ... a ... nedalo se to pouzivat.

[Tuxik]

Další skvělej nápad je: Budeme ty dokumenty ukládat do BLOBu v databázi. Cože? Bavíme se o stovkách GB ročně!!! Ale to se tak normálně dělá... Cože? A nešlo by je uložit na úložiště pod nějakým vygenerovaným jménem a do DB uložit jen původní název, vygenerovaný jméno a klidně nějaký další metadata? Ehmmm... eeeerrr.... noooo.... ale jooo... šlo by to... ale víte... hmmmm... máme to napsaný jinak... eeeee... ono by to bylo strašně drahý...

[Tuxik]

2j: To je to, co si ti malíři aplikací tak trochu neuvědomují... každej admin musí být zároveň hacker, aby se dokázal tím dnešním standardním shitem prokousat a buď ho opravit, nebo alespoň ukázat, kde přesně je chyba. K tomu musí být navíc i psycholog, aby jim dokázal vysvětlit, že to tím opravdu bylo, protože spousta expertů ti je schopná říct, že to chyba nebyla a že se náhodně "samo" opravilo něco jinýho, nebo tě rovnou obvinit, že jsi schválně zároveň opravil něco jinýho, aby jsi nebyl za blbce. Ale vrátit to zpátky do rozbitýho stavu už je pak nedonutíš, protože nemaj čas

[.]

Každý druhý sysadmin tady skuhrá, že nemá ani 30 tisíc hrubého ale koukám, že sebevědomí některým nechybí. Sice v diskusích vyplynulo, že nemá peníze pomalu ani na 8GB RAM, ale vše by napsal z voleje líp. Řekl bych, že na tebe všude čekají s otevřenou náručí, "j".

[Kamil Podlešák]

Mám sto chutí sem dát pár veselých historek z opačné strany (např. o tom jak aplikace sice uměla ukládat dokumenty na disk, ale admini trvali na tom že to bude v db dokud nezískají rozpočet mego/rok na komerční síťový FS), ale asi to nemá cenu... všechno je to typické selhání managementu.

Více na http://dilbert.com

[Tuxik]

Mám sto chutí sem dát pár veselých historek z opačné strany (např. o tom jak aplikace sice uměla ukládat dokumenty na disk, ale admini trvali na tom že to bude v db dokud nezískají rozpočet mego/rok na komerční síťový FS), ale asi to nemá cenu... všechno je to typické selhání managementu.

Více na http://dilbert.com

Ono je to potom taky o tom, jak máš nastavený všelijaký pravidla, procesy atd. Pokud ti spusta menších věcí jede na jedné DB a najednou ti někdo, kdo už tu DB používá nějakým normálním způsobem přijde s tím, že tam chce rvát BLOBY, tak je to na zabití. Mimochodem, perfektní filtr na supr čupr kůůůl aplikační malíře je Oracle. Perfektně se na tom rozezná firma, co má něco za sebou a dva bráchové, kteří se tváří jako nadnárodní korporát. Každej šašek zná MySQL, MariaDB, trošku lepší potom MSSQL nebo PG, ale jak šašek zaslechne Oracle, vyskočí mu pot na čele a začne se klepat

[ferren]

k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu. i jakakoliv modifikace je pak levnejsi. navic kdyz si to prase pak odejde jinam, tak je po nem daleko vetsi (a drazsi) svincik.

navic ani nemyslim ze bu pronajem vykonneho hw byl nejak levny. vloni me zajimalo, za kolik si muzu a kde pronajmout cpu/gpu pro rendering, kdyz je to prece tak levny, a vsude to bylo teda pekne mastny, tech nul v castkach bylo ponekud moc....

[Tuxik]

k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu. i jakakoliv modifikace je pak levnejsi. navic kdyz si to prase pak odejde jinam, tak je po nem daleko vetsi (a drazsi) svincik.

navic ani nemyslim ze bu pronajem vykonneho hw byl nejak levny. vloni me zajimalo, za kolik si muzu a kde pronajmout cpu/gpu pro rendering, kdyz je to prece tak levny, a vsude to bylo teda pekne mastny, tech nul v castkach bylo ponekud moc....

No tak logicky, když nějakej čmoudař nakoupí HW, platí za něj elektriku, údržbu atd, musí ty peníze dostat zpátky a ještě vydělat. Ano, nakupují pravděpodobně levněji, ale nebude to zase takovej rozdíl, aby se to finálně mohlo zákazníkovi ve velkým opravdu vyplatit. Jeden, dva stroje, pro malou firmu, možná ve světě jo, tam ušetřím jednoho drahýho člověka, ale u nás si tam posadí absolventa za pár drobných a ještě se k tomu bude starat o stanice. To platí o dedikovaným serveru. U sdílených serverů to bude jinak, pokud nepotřebuji nonstop výpočetní výkon, ale chci provozovat nějakej soukromej webík pro 3 návštěvy denně. Mám 2 VPS servery a platím za ně dohromady asi tolik, kolik by mě stál hoooooodně úspornej PC zapnutej doma jenom za energii. A bez starostí. Ale zase s tím rizikem, že i na těch pár webících, co tam běží, je občas poznat, že nejsou tak svižný. Samostatnou kapitolou právě může být ten rendering, komplikovaný výpočty, simulace atd. Tam se na jednorázovou akci vyplatí vysolit nehorázný peníze za blbý dva dny provozu, protože na HW, kterej bych za ty prachy koupil, to budu dělat rok.

[to_je_jedno]

k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu.

O tom nikdo nepochybuje. Myslim, ze tohle se resi pri porovnani postavit to na frameworku XY vs from scratch. ve vetsine FW se da psat ciste a stejne tak prasit. FW si vezme vice protoze je vice abstraktni, ale vyvoj je o nekolik radu rychlejsi. To je ta pointa.