Efektivita virtualizace

[RV]

Dne 24.2.2015 v 9:27 Petr Simek napsal(a):
> On Tue, 24 Feb 2015, RV wrote:
>
>>> To ne - kdyz definujete virtual tak mu pridelujete pocet jader, pamet
>>> a disk, takze pocet jader co dostane ty ma , vic ne.
>>
>> No psal jsem, ze to je zjednodusenej vyklad a asi to nebylo uplne
>> stastne...spis jsem mel napsat, ze v podstate muzete kazdemu virtualu
>> pridelit cely vykon masiny a diky nerovnomerne zatezi (ve virtualech)
>> se HW opravdu vytizi tak jako byste ty jadra jel tak jako byste mel
>> vykon CPU na 36GHz - nemyslel jsem to tak, ze jeden virtual dostane 36GHz
>
> Tohle uplne nechapu - kazdemu virtualu nemuzete pridelit cely vykon
> masiny - proste ma jen tolik jader kolik, mu pri vytvareni date.
> Ze kdyz pustite vic virtualu tak ten procesor vytizite vic je jasne
> ale nemuzete ani pridelit vic jader bezicim virtualum nez jich mate.
> Tohle neni moc prelevaci.
ano tak to myslim - proste dokazete vytizit masinu - zrejme si 
nerozumime - proste uspora je v tom, ze efektivne vyuziji HW - proste 
dokazu vytizit stroj o vykonu 36GHz (samozrejme ze ne jednim virtualem, 
ale to jsem myslel jako samozrejme, ze kvuli tomu se ta virtualizace 
dela) - my mame treba tri web servery s tim, ze dva nejvytizenejsi jedou 
z jednoho HW virtualizovane a treti jede fyzicky bez virtualizace a 
klidne bychom mohli ty servery jet vsechny z jednoho HW a nikdo by nic 
nepoznal

>
> To je zajimave . Ty stroje byly identicke a i ty OS+aplikace byly na obou
> identicke ? Jediny rozdil ze na jednom byl OS primo na HW a na druhem
> byl virtualizovany ? Databaze stejna a stejne nastavena ? Pokud ano
> stejne si nemyslim ze to zrychlila virtualizace , spis byl ten prvni
> server s vadnym RAIDem uz nejak nacaty a disk mu bezel pomaleji.
ano naprosto identicke - jsou to naprosto zamenitelne stroje - kdyz 
zamenim IP tak nikdo nepozna nic, ze by se neco zmenilo - i obsah SQL je 
stejny
to s tim raidem s tim nesouvisi - jede to tak i ted kdy je vse uz v 
poradku po te havarii uz produkce zustala na virtualu a fyzicka masina 
jede jako zaloha a poskytuje data pro testovaci server - ja z 
pochopitelnych duvodu tam nemohu delat nejake harakiri s testy, ale az 
aplikaci zmigrujeme do noveho prostredi tak servery stahneme sem do CB, 
kde je pouzijeme na lokalni SQL tak snad zbyde cas na to to nejak 
exaktneji proverit

> Mimochodem - otazka do plena - co preferovat na databazovem stroji ?
> Ja si myslim ze na databazovy stroj je treba pamet a to co nejrychlejsi,
> pak rychle disky a pak procesor s vetsim taktem ale mene jadry .
> Nekteri kolegove ale preferuji procesory s vice jadry i treba taktovane
> na mensi frekvenci.
>
> Mne osobne ta honba za mnoha jadry na databazovem stroji nedava smysl
> protoze je to hlavne o presouvani dat v pameti a na disku a ne
> o slozitych vypoctech . Prijde mi ze to nikdy nemuze ty jadra vyuzit.

hmmm to je tezke...hodne zalezi jak mate napsane aplikace a kolik 
vypocetnich zalezitosti presouvate na SQL - aplikace si muze sosnout jen 
surova data a vypocet provede klient coz je narocne na sit, disky a 
pamet serveru a nebo se cele zpracovani udeje v nejake ulozene porcedure 
a server vrati jen vysledek treba 42 ;-) - pak samozrejme setrite 
sitovou propustnost, vetsinou i diskove IO (server vetsinou muze lepe 
optimalizovat) a u pameti je to otazka - vetsinou pak musite navysovat 
pamet pro uzivatelske procesy, proceduralni kese, ale zase setrite data 
cache.
Hromada lidi vzyva SSDcka pro SQL servery - bohuzel u Sybase jsem prosel 
jen zakladnim skolenim na optimalizaci serveru plus se to vetsinou 
natukne na dalsich skolenich - nicmene vsude se zduraznuje, ze pokud je 
server optimalne vyladeny tak uspesnost ziskavani dat z kese je kolem 
99% tedy jen 1% veskereho objemu dat je ziskavano ctenim z DB - tedy z 
toho vyplyva, ze naprosto zasadni je rychla a velka RAM. Jakekoli 
diskove IO jsou nesmirne drahe.

Je to opradu pomerne slozite a ne vzdy dobre resitelne neb se tezko 
odhaduje co bude mit jake dusledky a navic se to muze casem menit. Treba 
i jen otazka blbych indexu - malokdo si uvedomuje, ze kdyz opentli 
tabulku v DB mrakem indexu pro kazdy dotaz co se kdy kde vyskytne, ze 
sice bude uzasne rychle data cist, ale zaroven to znamena, ze v pripade 
tabulky kam se hodne zapisuje to znamena neskutecne mnozstvi diskovych 
operaci, kterych se navic neda zbavit! musi se idnexy fyzicky zapsat na 
disk - ted zrovna migruji tabulku ktera zabira v DB vlastnimi daty 
397MB, ale indexy zabiraji 67GB - tedy uzivatel zapise jednim insertem 
1kB a server musi vygenerovat a zapsat dalsi 2MB indexu! pritom ten 
index se pouzije treba jednou za rok v nejake statistice. Ma smysl treba 
umistit tempDB na SSD disk, protoze tam se provadeji ruzne joinovane 
dotazy a obsah neni dulezity pokud by se neco podelalo.
Cela kapitola na dlouhe povidani jsou reseni zamku - jak na urovni 
klientu tak na urovni serveru - volby zamykacich schemat, reseni 
deadlocku apod. Ma to velke dopady na vykon systemu - resili jsme to 
ted, kdy se nam zmenilo zpracovani casti dat a vypadalo to na vymenu HW. 
Nakonec to vyresila zmena na klientovi a zmena zamykaciho schematu.

Dalsi vec je otazka je treba nastaveni "gapu" na datovych strankach - 
tedy kolik si ma server rezervovat mista pro eventuelni vlozeni dat mezi 
dva jine zaznamy - pokud jsou vety dlouhe a stranky male nebo gap maly 
tak server musi velmi casto rozpojovat page chain a vkladat cele nove 
stranky a to pak samozrejme zvysuje rezii na disku.

Takze tohle proste neni jednoduse zodpoveditelna otazka - u nas treba se 
CPU vetsinou na SQL flakaji - takze nam to treba umoznuje jet na levnych 
licencich omezenych na jeden socket a sest core - i tak je nevytizime - 
timpadem se dostavame na virtualizaci kdy mame jednou licenci pokrytej 
HW a SQLka nam bezi treba tri na jednom HW - coz je dalsi z vyhod 
virtualizace - tedy uspora licenci.

RV
---------------------------------

Pro případ, že tato zpráva obsahuje návrh smlouvy, Česká pošta, s.p. vylučuje možnost přijetí návrhu smlouvy s jakýmikoli změnami, dodatky či odchylkami. Navržení změn, dodatků či odchylek z Vaší strany považujeme toliko za podnět k dalšímu jednání o obsahu smlouvy. Až do okamžiku podpisu/uzavření smlouvy nejsme jakoukoli naší nabídkou vázáni. Výsledky jednání předcházejících uzavření smlouvy považuje Česká pošta, s.p. za nezávazné. Česká pošta, s.p. nenese žádnou odpovědnost za případné ukončení nebo přerušení jednání o smlouvě, a to bez ohledu na jeho důvod.

 

Tento e-mail včetně příloh může obsahovat důvěrné informace. Jestliže nejste zamýšlený adresát tohoto e-mailu, pak jakákoliv forma zveřejnění, tisk, kopírování, distribuce nebo šíření tohoto e-mailu a připojených příloh je přísně zakázáno. Pokud obdržíte tento e-mail omylem, oznamte to neprodleně jeho odesilateli a okamžitě tento e-mail včetně jeho příloh trvale vymažte ze svého systému. Odesilatel e-mailu neodpovídá za jakoukoliv škodu způsobenou modifikacemi či zpožděním přenosu e-mailu.


In the event that this email contains a contract proposal, Česká pošta, s.p. hereby excludes acceptance of the contract proposal with alterations, amendments and adjustments of any nature. Your proposal of alterations, amendments and adjustments may only be subject of further contract negotiation. Česká pošta, s.p. is not bound by any of its offer until the contract is concluded. Česká pošta s.p. considers the result of contract negotiations preceding the conclusion of contract non-binding. Česká pošta, s.p. is not liable for termination or interruption of any contract negotiation for whatever reason.

 

This e-mail and any attached files may contain confidential information. If you are not the intended addressee of this e-mail, you are hereby notified that any disclosure, printing, copying, distribution or dissemination of this e-mail and any attached files is strictly prohibited. If you receive this e-mail in error, please immediately notify the sender and permanently delete this e-mail and its attachments from your system. The sender of this e-mail does not accept liability for any damage that may be caused by any modifications or delay in the transmission of it.