dual Xeon database server - how to ?

Pitanje za iskusne.

Potrebno je uraditi upgrade masine Dell PowerEdge 2650 (2u rack server 2x2.8Xeon, 3GB mem) koja radi kao database server pod win2003serv, baza je MS SQL. Trenutno je u masini (ne) iskoriscen ugradjeni SCSI kontroler na koji su zakacena 2+2 diska u mirror RAID-u (c: i d: )

Problem je u tome sto baza koja je 3 meseca u radu vec dostize velicinu od oko 4GB i pretrage, indexiranje i ostale radnje pocinju da trose previse vremena, a klijenata ima sve vise. Posto sam upitan sta bih promenio u sistemu da se to ubrza - predlozio sam upgrade disk sistema na RAID 5 scsi sa dosta kesh memorije i diskove sa hotswap fijokama, ali nazalost moje iskustvo za ovakvim uredjajima se svodi 'znam da ima i video sam na slici'. Da li neko ima vise iskustva i moze da predlozi neki konkretan model ? Da li bi neko od vas imao neki drugi predlog (hardverski) koji bi doneo ubrzanje obrade podataka iz ovolike baze?

Hvala na odgovorima...

Cekaj, sad nije jasno koji su diskovi uopste nakaceni (IDE ili SCSI) i koji je to RAID - 10 ili 0+1?

1. uradi se test koliko je odnos pogodaka u kesiranju SQL Servera; ukoliko je manji od 98-99%, problem je u tome sto nema dovoljno memorije ili se koristi ona verzija MS SQL servera koji ne vidi celu memoriju - neke verzije vide samo do 2GB, a novije do 64GB RAM-a.

2. pogledao sam karakteristike tog poweredgea - on ima valjda dvokanalni SCSI Ultra160 RAID kontroler sa 128MB kesa. To bi trebalo da je dovoljno brzo. To jest, ako se koriste odgovarajuci brzi diskovi (4 kom) koji su mirrorovani pa stripovani. Trebalo bi pogledati da li sve radi kako treba vec sa ovim postavkom.

3. klasika - svi servisi viska moraju da lete. To ukljucuje i antivirus - sav drugi pristup serveru sem sql servisa se blokiraju, te virus ni ne moze da dodje kod njega. Naravno, sve do gluposti kao sto je screen saver. Samo sql server da radi.

4. Ne mozes sve prepustiti hardveru, nesto mora i projektovanje softvera da odradi. Indeksiranje, redovna normalizacija baze, sredjivanje logova, itd. sto se tice DB administracije, i naravno, zavisi kako je programer uopste optimizovao koriscenje i vracanje podataka (ako je uopste razmisljao o optimizaciji)

5. Ukoliko je sve ovo gore ok, mozda moze da se napravi malo drugaciji raspored. Imas tu PCI-X slotove, uzme se jedan dodatni PCI-X RAID kontroler (ne mora 5, moze samo da podrzava 0, 1, 0+1 / 10 i jbod). Na njega se vezu novi diskovi (makar dva u mirror) i baza se konfigurise da tamo ide tempdb baza i/ili logovi, dok glavna baza ostane je ovom postojecem raidu.

6. Ukoliko je posao stvarno toliko veliki (veliki broj klijenata sa velikim brojem zahteva) da nista od ovog ne pomaze, onda posao definitivno prerasta upotrebu jednog servera i tada ne gine jos jedan, te njihovo povezivanje.

Diskovi su SCSI, ima ih 4 ukupno (maxtor), Dell manager software mi prijavi da ih ima 2 ukupno, i da su stavljeni u Array, cini mi se da je mirror (prijavi mi 68.xxGB po disku). Kontroler na koji je sve zakaceno se identifikuje kao Perc3/Di.

1. Verzija koja je instalirana je MS SQL 2000 developer edition, ver 8.00.760 (sp3) dodeljeno mu je od 2 do maksimum 3gb memorije. U task manageru prijavi da koristi 1.7-1.8GB memorije.

3. masina radi samo ovo, tj nema nista osim par alata i SQL servera na njoj, servisi su nazalost ostavljeni svi koji su sa klot instalacijom 2003 servera instalirani...

4. reindexiranje se radi svaki dan, log svakih pola sata, backup baze svakodnevno. U ovom trenutku baza koristi drugi Array diskova i sama je na njima (nista od drugih podataka se ne upisuje na taj disk).

Problem nastaje kada se velike kolicine podataka prebacuju (brisu, obradjuju i pisu nazad jedan po jedan) iz jedne tabele u drugu npr. (reda velicine 5.000.000 recorda po tabeli)... trenutno je ovaj pristup u reviziji pa ce programerski biti resen drugacije... ali generalno ostaje problem sporog odziva masine, tako da treba ubrzati sistem dok se ne uradi nova revizija baze.

milanbb je napisao(la):

... ali generalno ostaje problem sporog odziva masine, tako da treba ubrzati sistem dok se ne uradi nova revizija baze...

Kliknite za proširenje...

Stavi swap fajl na novi HD pa probaj...

Cekaj, koji sad drugi array? Kada si napisao 2+2, ja sam pomislio da su po dva diska mirrorovani i onda takvi parovi stripovani - to ti je optimalna konfiguracija za diskove za SQL servere. Medjutim, sada ispada da su to dva potpuno odvojena mirrora?
I koji Maxtori su u pitanju? Maxtor je imao sve i svasta u ponudi, od preuzetih starih Atlasa III na kojima je samo prelepljena nalepnica preko starog "Quantum" stikera do njihovih poslednjih 15K Atlasa.

Elem, opet cu da ponovim ono sta je izgleda proslo neprimeceno: "spor odaziv masine" moze da ima uzroke na nekoliko polja -> moras prvo da ustanovis u kojem od njih je usko grlo, pa onda resavas taj deo; ne moze se svaki hw bottleneck problem resiti ubrzavanjem hdd podsistema. Dakle, moguce je:
1. CPU je spor
2. nema dovoljno memorije
3. hdd podsistem je spor
4. mrezni pristup je spor
5. koriscenje baze (iz sw ugla) je neoptimizovano

Dakle, redosled kojim bih ja isao je sledeci -> svi servisi viska, antivirusi, firewallovi, skrin sejveri, itd sta ne treba ili se ne koristi moraju da lete. Time se koliko-toliko smanjuje CPU load. Zatim sa tako smanjenim CPU loadom bih proverio memoriju, jer memorije imas i viska u odnosu na ono sta se koristi. MS SQL server ima Cache Manager - proveriti Cache Hit Ratio. Ako server ne radi nista drugo, ne znam zasto je ostatku sistema koji nista ne radi ostavljeno 1GB RAMa da zvrji prazno?
- dati SQL serveru vise RAM-a i poigrati se sa MemoryManagerom, BufferManagerom i CacheManagerom SQLservera.
- probati i onaj Index Tuning Wizard
- kod transaction logova disejblovati automatic shrinking; procenat rasta log fajlova povecati. Ukoliko je suvise mali, sql server mora to da radi cesce i tu usporava sistem
- slicno vazi i za tempdb; procenat rasta ne treba da bude podesen na suvise nisku vrednost.

Ukoliko je na prvom mirroru sistem, a na drugom baza, ne treba mesati tempove i swapove izmedju njih zbog fragmentacije. Pogledaj kako i koliko ti se menja swap od samog windowsa. Ne bi trebalo mnogo, posto SQL server koristis svoje interne mehanizme, tj. tempdb za mnoge stvari. Tada mozes da budes malo darezljiv i fixiras velicinu swapa i tako izbegnes fragmentaciju diska na njegov racun.
Pare na kesirani RAID5 ne bih bacao, ali bih za max peformance uradio ovakav raspored - ova cetiri diska vezati u RAID10 (0+1), gde bi oni dakle bili i mirrorovani i strippovani (RAID5 vezom ne bi dobio nista brze performanse sa istom kolicinom diskova). Mozda u tvom slucaju vec ovo bude dovoljno osetno ubrzanje koje resava problem. Ukoliko i to ne resava problem, onda bih uzeo neki 64-bit SCSI RAID kontroler (adaptec ima fine low profile modele koji pasuju u niska rackmount kucista) i dva brza 15Krpm diska - recimo seagate cheetah 15K.3 i vezao ih u stripe. Na njih prebacio samo tempdb (dok bi baza ostala na onom postojecem RAID 10 lancu). Od analize sadasnjeg resenja (tj velicine tempdb-a) zavisi koliko bi ti 15K diskovi veliki bili. Uz revidiranje softverskog pristupa, to bi generalno trebalo da je dovoljno.

I poslednja stvar zavisi od koncepta i namene baze u odnosu na transakcije. Jedna krajnost je malo transakcija koje nose dosta podataka, a druga krajnost je velika kolicina transakcija sa po manje podataka. Ukoliko se radi o velikom broju transakcija, preporucljivo je da se i za log ima poseban dedicated disk - ne mora biti neophodno mirorovan ili strajpovan, vazno je samo da je odvojen, dedicated disk. Ukoliko se strpa na isti lanac gde je i tempdb u ovakvom scenariju, takmicice se medjusobno ko ce koga vise da fragmentira i uspori. Dakle, pojedina hw resenja ovde zavise i od programerskog resenja, pa treba videti sa tim ljudima koji revidiraju bazu sta i kako planiraju da urade.

Pa nisam se dobro izrazio za drugi array diskovi su vezani 2 po 2, znaci od dva diska je napravljen mirror i sada ih ima 2 (virtualna) od po 68GB, ne znam koji su maxtori u pitanju, posto nemam mogucnost da to proverim jer je masina zatarabljena po pitanju neta - samo terminal services.

Ovih 5 stavki nisu prosle neprimecene, i ja sam imao takvu ideju (da nesto od toga ne radi ko svet). Ali imam veoma lose informacije o masini.

Javljam se kada probam sve predlozeno.

Hvala mnogo.

Jos jedna stvar koju sam zaboravio - ukoliko se sql server drnda samo u radno vreme, moze da se scheduluje automatski defrag kada nema zaposlenih, naravno.
Za ovo ostalo vidi prvo sve moguce stvari koje se ticu optimizacije i podesavanja postojece opreme. Pa tek kada to ne pomaze, vaditi budjelar za dodatni hardver.

Jačim hardverom možeš poboljšati performanse ali ne u tolikom obimu koliki očekuješ. Pitanje je: kako je baza isprojektovana, na koji način joj klijenti pristupaju i kako je baza uopšte raspoređena fizički po hard diskovima.

Ako je baza veličine 4GB (data fajl, a ne transaction log) i sastoji se od jednog fajla - onda je to loše zamišljeno. Koliko slobodnog prostora u toj bazi ima? Da li nam možeš iskopirati podatke koje ćeš naći na TaskPad-u u Enterprise Manager-u?

Bazu te veličine bi najbolje bilo logički odvojiti u nekoliko zasebnih fajlova, i u jednu grupu smjestiti one podatke kojima korisnici moraju pristupati promptno (što brže), a u drugu grupu smjestiti one podatke koji se kopiraju i prebacuju. Ako se to kopiranje ne mora obavljati u kontinuitetu tokom dana - onda tu operaciju treba naštimovati da se obavlja tokom noći u okviru Maintenance Plan-a.

Da li korisnici prilikom pristupa bazi - eksplicitno otvaraju konekciju? Ako je to slučaj - to nije dobro, i treba ih usmjeriti kroz MTS (Microsoft Transaction Server). Možda pristupaju podacima putem Web servisa. Koliko je to sporo - sporo? Koliko je brzina u radu sa bazom pala u tih 3 mjeseca? Duplo ili više?

Rad sa jednim fajlom od 4GB je spor u svakom slučaju (bilo da se radi o video fajlu, ili sql server bazi), zato treba prvenstveno optimizovati taj dio na sql serveru (izdijeliti taj fajl u logičke grupe), pa tek potom (k'o što reče Guru) otvoriti buđelar.