Vyhodnost L2 cache

azeleny na csas.cz azeleny na csas.cz
Čtvrtek Únor 15 10:15:05 CET 2001


DDV

> -> planujeme koupeni noveho serveru a rozhodujeme se nad 
> velikosti L2 cache
> -> u PIII. Je vyhodne koupit procesor na nizsi frekvenci s 
> velkou (2MB) L2
> -> cache nebo rychlejsi procesor s mensi L2? Mate nekdo prakticke
> -> zkusenosti nebo stranku s benchmarky?
> -> Server by mel byt 4xPIII(1GHz/1MB L2 nebo 700MHz/2MB L2), 
> 2-4GB RAM,
> -> operacni system samozrejme Linux a provozovana uloha 
> Oracle s cca 15 GB
> -> dat a plus dalsi vicemene nepodstatne ulohy.

Ladite-li system pro Oracle, pak je potreba vedet, jaky Oracle (predpokladam
ze Enterprise, jinak by takoveho stroje bylo skoda a nejsem si jist zda pro
takovyto HW vubec existuje workgroup verze).

Je ton system OLTP, nebo DDS?
Pokud je to DDS databaze, pak se vice CPU hodi, nezapomente ovsem, ze aby z
toho neco bylo musite dobre vyladit paralell execution (v ora7 paralell
query) a paralell level na vybrane tabule.

Pro OLTP (ale DDS to oceni take) bude nakonec stejne nejvice zalezet na
discich, mohu-li doporucit vyberte si mirror (treba do RAID10 aby jste mel
dostatecne misto). Na vykonu se to podle me zkusenosti zatracene pozna treba
v porovani s RAID5 (i pres 64MB case na RAID), stripe nekolika mirroovanych
disku mi vykonove dost pomohl.
Pokud stavite novy stroj se vsim vsude, mejte databazi rozume rozdelenou do
vice tablespaces a umistete jednotliva tablespaces na ruzne kanaly (k poli)
-- takovy 4 kanalovy RAID me osobne da vetsi vykon, pokud jej mam jako 4
samostatne mensi RAID10, nez jeden veliky byt s 4kanalovym pristupem.
Dobrym rozlozenim redologu do skupin na jednotlive kanaly (logy v jedne
skupine mit na ruznych discich-kanalech) a rozdelenim tabuli do tablespaces
dostanete z diskoveho systemu opravdu hodne i na UWSCSI, neni treba mit na
vsechno optiku:-)

Pro oba typy pak plati nektere veci spolecne, treba ciselnikove tabule drzet
cele v RAM (tedy pokud jsou smysluplne velikosti)...

V mem pripade je DB mixovana ani OLTP ani DDS a vykonu pomohlo dat data
pouzivane z velke casti pro data decision cast na jeden kanal RAIDu - tato
cast neni casove kriticka a cas, kde jde o rychle ukladani a cteni (mene
pocitani) dat s co nejkratsimi odezvami jsem rozdelil mezi ostatni disky
(kanaly RAIDu).

Jo, podstatna vec, Oracle mi tu bezi naneststi na NTcku, takze netvrdim, ze
na Linuxu (daleko lepsi prace s cashe...) nemuze byt jedno velike pole
pripojene pres 4 kanaly lepsi, nicmene ja bych stejne osobne volil č mensi
RAIDy uz kvuli bezpecnosti redologu.

a.
----------------------------------------------------------------------- 
Aleš Zelený (OK1UUE)
Česká spořitelna a.s. 
Na Perštýně 1 
113 98 Praha 1 
Email: azeleny na csas.cz 
tel: +420 2 24995 236 
----------------------------------------------------------------------- 
Due to technical difficulties tomorrow has been postponed indefinitely. 



Další informace o konferenci Linux