[2000] Performance problemen Quad Xeon 1.6 Ghz sqlserver*

[ArjanC]

Wij hebben hier 2 clusters staan.
deze bestaan uit dezelfde hardware, de ene is TEST en de andere PRODUCTION.

hardware :
Compaq Proliant DL580
Memory : 6Gb RAM
CPU's : 4* 1.6Ghz Pentium Xeon
Harddisks 4*36Gb 15K
Raid setup : RAID 5 (4*36Gb)
Volumes :
C : System
D : Data (SQL Database)
E : Install
F : Transaction Logs

Software:
Windows 2000 Server
SQL Server 2000
Draait Navision.

De servers zijn geclusterd dmv een dedicated 1000Gb Fiberoptic netwerkkaart en Legato.
de SQL database is ongeveer 45Gb

Nu is het probleem dat hij best wel traag is. als wij in TEST wat veranderingen aanbrengen in de database dan groeit de transaction log als een idioot en duurt het ongeveel 7 a 8 uur voordat hij klaar is. in Production doet hij er even lang over.

Nu hebben we een vendor die voor ons ook testen draait en als hun hetzelfde doen duurt het ongeveer 3 uur.

hun hardware :
Intel Pentium 4 2.8Ghz
2Gb Ram

dat is wat de programmeur mij wist te vertellen.

Nu dacht ik dat als je meerdere Xeon processoren heb dat je dan het geheugen moet verdelen onder de aantal processoren ? dan zou het 6Gb / 4Cpu's = 1,5 Gb per CPU zijn ?
of zit ik nu helemaal verkeerd?
we hebben al geprobeerd om de database te prunen (SQL Litespeed) maar nog steeds is hij niet echt snel.

iemand een Idee?

[sanfranjake]

Ik zet even [2000] in de topictitel per de Windows Operating Systems - Policy. Wat heb je zelf al gedaan om dit op te lossen?

Is Windows maar ook SQL uptodate, dus met SP4 en navolgende updates?

[ Voor 18% gewijzigd door sanfranjake op 29-09-2005 17:18 ]

[elevator]

Veel databases zijn eerder IO bound dan CPU bound - dat je enkel met 4 disken en dan ook nog eens in RAID5 werkt (en je hebt het niet over een uitbreiding op je SmartArray, dus ik gok dat je ook nog eens cacheloos werkt) zou wel een en ander aan IO problemen kunnen opleveren

Je zou eens met http://support.microsoft....aspx?scid=kb;en-us;224587 ,en http://download.microsoft...dfeae4b45/subsys_perf.doc kunnen beginnen om te zien of je er iets mee kan

[ArjanC]

Bedankt voor de reply's

Ik weet niet zeker of de SmartArray is uitgebreid.
hier zijn de instellingen :

Smart Array 5i Controller
Controller Smart Array 5i Controller
Bus Interface 64-Bit PCI
Controller Location Embedded

Hardware Revision B
Firmware Version 2.38
Rebuild Priority Low
Expand Priority Low
Current Surface Scan Delay 15 sec
Number of Arrays 1
Number of Logical Drives 1
Number of Physical Drives 4
Physical Drives Attached to Port 2 SCSI ID 0, 36.4 GB
SCSI ID 1, 36.4 GB
SCSI ID 2, 36.4 GB
SCSI ID 3, 36.4 GB

All Physical Drives Assigned Yes

Array Accelerator
Present Yes
Cache Status Enabled
Accelerator Ratio 50% Read /50% Write
Read Cache Size 24 MB
Write Cache Size 24 MB
Battery Pack Count 1
Battery Status OK


Maar zou het sneller gaan als we gebruik maakten van Raid 1+0 of 2x Raid 1 ?

[Jrz]

RAID-5 is vaak niet zo erg snel, maar 8 uur lijkt me erg lang.
Wat voor veranderingen zijn het?

Als het bijv. een bulk update / insert is, kan je kijken of je je indexen eraf kan halen, en daarna er weer op.

Je kan in sqlserver ook je transaction log instellingen veranderen (kijk ook even of hij je geheugen en cpus wel goed gebruikt.)


Maar je hebt 2 van die bakken, en is samen 1 cluster, en op diezelfde cluster heb je dan 2 databases draaien, eh?

Ik zou die andere vendor ook even vragen alles op een cluster te draaien.

[elevator]

burp2001 schreef op vrijdag 30 september 2005 @ 08:54:
Present Yes
Cache Status Enabled

Dat is in ieder geval positief

Maar zou het sneller gaan als we gebruik maakten van Raid 1+0 of 2x Raid 1 ?

Ga eerst even met de links die ik je eerder gaf aan de slag - daarmee kan je eerst zelf vaststellen dat je echt een IO probleem hebt

Ik snap een ding niet - die 4 x 36GB is vermoedelijk internal storage in de DL580, maar voor een cluster heb je ook shared storage nodig en horen je databases + transactionlogs ook daar op te staan. Welke config laat je me nu exact zien?

[ Voor 23% gewijzigd door elevator op 30-09-2005 12:19 ]

[richard_kraal]

mja, het gebruik van een 5i controller is natuurlijk gewoon klote, dit is alles behalve een fatsoenlijke raidcontroller (ok ok ok, voor os mirror is het wel aardig), voor echt heftig gebruik heb je een 6400 serie met een lekkere cache nodig)

daarnaast, is raid5 niet echt een slimme optie, veel te intensief, ga voor raid10 is het advies, en het liefst de volgende config

os - raid1
logs - raid1
db - raid10

kijk ook eens naar je je physical disc queue lenght in je performance monitor!

maak een screenshotje van een minuut monitoren (met actief gebruik van de DB natuurlijk!)
post die hier ff

[lier]

Hebben jullie niet een "fatsoenlijke" DBA-er rondlopen die eens kan kijken wat bij jullie de performanceproblemen veroorzaken ? Performancecounters is hier het keyword.

Inderdaad, je schijfindeling is niet echt oke, maar misschien is er wel iets anders de bottleneck ?

[richard_kraal]

lier schreef op vrijdag 30 september 2005 @ 13:55:
Hebben jullie niet een "fatsoenlijke" DBA-er rondlopen die eens kan kijken wat bij jullie de performanceproblemen veroorzaken ? Performancecounters is hier het keyword.

Inderdaad, je schijfindeling is niet echt oke, maar misschien is er wel iets anders de bottleneck ?

dat snap ik idd ook niet

zo'n giga server en je weet uiteindelijk niet eens hoe het werkt en waar je moet zoeken als het 'niet lekker werkt'

beetje vaag als je het mij vraagt

en bij zo'n server is die schijfcombi gewoon super fout, een 5i is een traag ding en laat staan dat dat ding in raid5 presteert.....

[P_de_B]

als wij in TEST wat veranderingen aanbrengen in de database dan groeit de transaction log als een idioot en duurt het ongeveel 7 a 8 uur voordat hij klaar is.

Begin eens met bovenstaande uit te leggen? Wat verander je, data of objecten? Hoe groot is het transactionlog? Is hij 8 uur met 1 query bezig etc etc. Met alleen zo'n kreet kunnen we weinig.

[mbaltus]

De algemene conclusie mag wel zijn dat dit probleem heel veel verschillende oorzaken kan hebben. Hardware, instellingen van OS en SQL Server, layout van de database (indexen, etc.), "slimheid" van de bewerkingen, etc.

Wel ben ik het met de meeste eens dat er aan processoren en RAM een overvloed is en dan een veel te eenvoudige RAID controller in gebruik. Een goede Smart-Array controller met minimaal 128MB battery backed cache klinkt veel logischer in deze configuratie. Maar het echte voordeel hiervan blijkt pas uit de performance counters. Laat eens een tijdje perfmon meelopen, met daarin een paar slimme counters voor geheugen, processor en disk I/O, dan kun je al veel beter bepalen of en zo ja waar de bottleneck zit.

[The Eagle]

@Mbaltus: eensch, maar ik denk persoonlijk dat je het eerst in de hardware moet gaan zoeken, aangezien een vergelijkbare HW / SW-setup de zelfde resultaten geeft, en een andere setup met identieke software maar andere HW betere resultaten, verwacht ik niet dat het in de software zal zitten. Bovendien wil je bij een ERP-pakket als Navision in principe niet teveel aan je DB-instellingen veranderen - dan ben je mogelijk je certificering van de leverancier al kwijt.

Ik denk persoonlijk dat het idd in de RAID gezocht moet worden. Waar ik verder naar neig is het feit dat er volumes gebruikt worden, ipv fysieke arrays / schijven. Ik zou zelf gekozen hebben voor een setup waarbij meerdere (al dan niet RAID) arrays / disken gebruikt werden. Want nu komt echt alles op de (volgens anderen toch al brakke) RAID-5 setup terecht...voor je thuis-PC weet je toch ook dat aangeraden wordt om je swapdisk op een fysiek andere schijf te zetten als dat mogelijk is? Dus ik zou het eerst in die richting gaan zoeken

[Question Mark]

burp2001 schreef op donderdag 29 september 2005 @ 10:45:
De servers zijn geclusterd dmv een dedicated 1000Gb Fiberoptic netwerkkaart en Legato.
de SQL database is ongeveer 45Gb

elevator schreef op vrijdag 30 september 2005 @ 12:18:

Ik snap een ding niet - die 4 x 36GB is vermoedelijk internal storage in de DL580, maar voor een cluster heb je ook shared storage nodig en horen je databases + transactionlogs ook daar op te staan. Welke config laat je me nu exact zien?

Legato heeft een eigen clusterpakket. Deze clustersoftware gebruikt geen shared storage en is dus ook geen clusteringsolution alá Microsoft Clustering services. Deze software synced continue een hiervoor aangewezen partitie tussen beide 'nodes'. In dit geval waarschijnlijk de partitie waar de SQL database opstaat. TS heeft het ook over W2K als OS, geen W2K Advanced Server. MS clustering is dus al uitgesloten.

Behalve de standaard I/O acties op de database, loopt deze software dus ook continue deze partitie te syncen...

Ik heb datzelfde pakket op mijn werk ook even gedraaid in een testomgeving. Kan overigens even niet meer op de naam van het pakket komen. Legato is nl. de leverancier, niet de naam van het softwarepakket .

[elevator]

Op die manier - ik had Legato in deze context eigenlijk als backup pakket geclassificeerd en niet als cluster opstelling.

In dit geval lijkt het me helemaal een rampzalig disk setup en snap ik niet wie deze oplossing op deze manier verkocht heeft.

[ArjanC]

okay, eindelijk een update.

dit is dus het hele verhaal. ik zit hier nog niet zo lang dus weet nog niet hoe alles hier werkt maar.

de database en trans.logs staan op een filer. een NETAPP server.
alle servers in het cluster staan dmv iSCSI met de NETAPP filer in verbinding.

de filer bestaat uit 4 'planken' met hdd's (ongeveer 8 per stuk)
deze staan per 8 in RAID met 1 hdd voor backup.
daarna is alles gedeeld in volumes.

(dus 1 raid kan meerdere volumes bevatten)

tada.. hier zijn dus de performance problemen.

legato synched 2 schijven tussen het custer (constant) dat zijn dus de schijven die op het cluster zitten.

ik weet niet wie dit verzonnen heeft of wie dit in godsnaam verkocht heeft.

idd rampzalig.

[elevator]

Ben je nou al eens met perfmon bv. aan de slag geweest om eerst te bewijzen dat je echt een IO probleem hebt? 4 volumes gekoppeld aan een server hoeft helemaal niet per se een performance probleem te zijn - theoretisch heb je 28 spindles ter beschikking wat toch behoorlijk wat IO kan verzetten.

[richard_kraal]

pas geleden toevallig ook een test gedaan op 'een' NETAPP (alla , geen idee wat voor apparaat, kweet alleen dat je er een ISCSI verbinding mee kon opzetten van max 2GBbit, na wat simpele tests hebben we dit hele verhaal/idee maar snel in de prullenbak gegooid

de performance was namelijk slecht, echt HEEL slecht, snelheden van een cheapass server waren namelijk al beter dan van die netapp... daarbij kwam het er op neer dat wij met onze sql praktijken de complete backbone dichttrokken en daardoor andere mensen geen prio meer kregen

zo'n net app kost klauwen met geld

toch ga ik liever voor een dikke ML570 server