Trage databaseserver

[Verwijderd]

Ik ben bezig met een applicatie waarin online verzekeringspremies worden berekend. Deze premieberekeningen worden door een externe partij geleverd, en zijn geprogrammeerd ineen VB/mssql omgeving.

Per berekening worden ongeveer 20 * 80 queries uitgevoerd. De zwaarte van deze queries is voor mij niet inzichtelijk, net als de rest van de software.

1 berekening duurt nu ongeveer 40 seconden.

De serveropstelling: 1 bladeserver (enkel CPU en RAM) als applicatieserver, en 1 database-server (met wél een eigen HDD). Beide servers hebben een piek-CPU en RAM- gebruik van 25%.

We willen nu de berekeningssnelheid omlaag halen, zónder iets in de programma's aan te passen, aangezien die voor ons een blackbox zijn.

Heeft iemand een inzicht in waar de bottlenek kan zitten in dit snelheids-verlies, en hoe dit valt te versnellen. En wat zou een ideale database-server zijn voor deze situatie?

Thanks!

[Gé Brander]

Ik denk dat de enkele harddisk (als ik je goed begrepen heb) hier de bottleneck is. Te weinig I/O mogelijkheiden. Maar als het een black box is, dan kan je daar weinig aan doen. Tevens Index optimalisatie zou lastig worden als het een balck box is.

[Verwijderd]

De servers zelf kunnen we dus wel gaan configureren. Enkel de inhoud van de database-server, en de applicatie zelf zijn voor mij een blackbox. Ik zoek dus naar mogelijkheden om de server zelf wel te versnellen.

[FastBunny]

Aan de hand van hoe zwaar de query is kan hier veel I/O verkeer voor nodig zijn, zeker als de database slechte statistieken heeft en/of niet geoptimalizeerde indexen etc. Voor databases is het aan te raden om een eigen harddisk te hebben die niet gedeeld wordt door zowel de databaseserver als de application server. En het liefst in een RAID10 array met snelle SCSI/SAS schijven

[djluc]

Kan je wel een kopie maken en op een ander systeem testen? Zoja: Wat is de tijd die het duurt als je het op een recente PC zet zonder verder load?

[Verwijderd]

Valt de I/O doorvoer te meten op zo'n server?

[Equator]

Tja, zonder meer info over de hardware, tabellen, indexeringen, sql config kan je vrij weinig over de performance zeggen.
Heb je al eens gesproken met de toko die de applicatie levert? misschien kunnen zij nog wat in de DB aan indexing oplossen, en ben al veel verder.

Verwijderd schreef op dinsdag 21 augustus 2007 @ 09:42:
Valt de I/O doorvoer te meten op zo'n server?

Tuurlijk.. Start je task manager maar eens, en kijk eens naar de verschillende kolommen die je kan selecteren. Het is niet direct een duidelijk overzicht, maar het geeft wel aan of er excessief IO verkeer optreedt.

Natuurlijk heeft Windows ook een ingeboude performance couter die je daar voor kan gebruiken.

Edit: BackSlash

[ Voor 47% gewijzigd door Equator op 21-08-2007 09:48 ]

[alt-92]

Verwijderd schreef op dinsdag 21 augustus 2007 @ 09:42:
Valt de I/O doorvoer te meten op zo'n server?

Even gelet op wáár je dit post:
Wat denk je zelf?

perfmon e.d. zijn je vriendjes in deze, en uiteraard is het van groot belang te weten (navragen dus bij je leverancier) wat voor config ze er in die SQL doos hebben gestopt.

[edit]

offtopic:
Equator: @ icon

[ Voor 6% gewijzigd door alt-92 op 21-08-2007 10:06 ]

[Verwijderd]

alt-92 schreef op dinsdag 21 augustus 2007 @ 09:47:
[...]

Even gelet op wáár je dit post:
Wat denk je zelf?

perfmon e.d. zijn je vriendjes in deze, en uiteraard is het van groot belang te weten (navragen dus bij je leverancier) wat voor config ze er in die SQL doos hebben gestopt.

Je hebt gelijk Mijn vraag was ook meer hoe het valt te meten

[Verwijderd]

Dit is een handig tooltje.

[Boss]

Heb je de mogelijkheid om de database wel een keer naar een eigen machine te halen en daar wat queries te optimaliseren? Dan kan je in ieder geval die leverancier eens om zijn oren slaan.

Ik denk dat je met hardware optimalisatie slechts een kleine performance verbetering kan gaan realiseren.

[Verwijderd]

Verwijderd schreef op dinsdag 21 augustus 2007 @ 09:42:
Valt de I/O doorvoer te meten op zo'n server?

En wat wil je dan zien aan de I/O? I/O is zo'n counter die altijd in een SLA met klanten staat, maar echt helemaal niets zegt over een bottleneck op een disk. Een beetje techneut kijkt naar de disk queue length als eerste...

[Verwijderd]

Boss schreef op dinsdag 21 augustus 2007 @ 10:47:
Ik denk dat je met hardware optimalisatie slechts een kleine performance verbetering kan gaan realiseren.

Dit snap ik niet goed. Er zal toch ergens een zwakke schakel zitten in de snelheid? Als de server nu maar 25% gebruikt wordt, zou het toch vanzelf 4x zo snel moeten kunnen? (als er niet een andere zwakke schakel is)...

[Freezerator]

Dat je cpu/ram 25% maar wordt gebruikt, wil niet zeggen dat hij 4x zo snel kan worden als je schijf I/O al 100% gebruikt wordt. Bedoel, per berekening 1600 queries...

[Boss]

Verwijderd schreef op dinsdag 21 augustus 2007 @ 12:13:
[...]


Dit snap ik niet goed. Er zal toch ergens een zwakke schakel zitten in de snelheid? Als de server nu maar 25% gebruikt wordt, zou het toch vanzelf 4x zo snel moeten kunnen? (als er niet een andere zwakke schakel is)...

Het kan zo zijn dat SQL Server is gelimiteerd op 25% CPU belasting...

[Verwijderd]

Freezerator schreef op dinsdag 21 augustus 2007 @ 12:21:
Dat je cpu/ram 25% maar wordt gebruikt, wil niet zeggen dat hij 4x zo snel kan worden als je schijf I/O al 100% gebruikt wordt. Bedoel, per berekening 1600 queries...

In dat geval zou dus een setje snelle schijven in een RAID10 opstelling de boel kunnen versnellen?

edit:

De leverancier van deze software antwoord nu "...database is al helemaal geoptimaliseerd voor zover mogelijk. Dat wil zeggen dat alle zinvolle indices aanwezig zijn. Queries zijn geoptimaliseerd met behulp van een query analyzer..."

[ Voor 24% gewijzigd door Verwijderd op 21-08-2007 13:52 ]

[Freezerator]

Ik zou eerst eens gaan meten of het de IO bv is, en als dat het is, dan zou dat een oplossing kunnen zijn. (raid 10 + een fatsoenlijke controller + dito schijven)

[Equator]

Misschien kan de topicstarter een duidelijke opzet tonen van de database server zoals deze nu in elkaar zit. Specs dus

Want daar ben ik sinds de topic start nog niet echt veel wijzer over geworden..

[Gé Brander]

Freezerator schreef op dinsdag 21 augustus 2007 @ 14:58:
Ik zou eerst eens gaan meten of het de IO bv is, en als dat het is, dan zou dat een oplossing kunnen zijn. (raid 10 + een fatsoenlijke controller + dito schijven)

Veelal is er meer te halen uit optimalisatie van indexen en queries dan uit extra schijven. Maar dat wil niet zeggen dat dat hier ook het geval is.

[ODF]

Het RAM kan ook de bottleneck wezen.

[Boss]

En als je aan de leverancier vraagt wat zij voor performance halen, en wat ze zelf redelijk vinden?

Misschien vinden zij 40 sec heel normaal is dat volgens hun al het best haalbare.
Dan moeten ze dat maar aan jullie gemeenschappelijke opdrachtgever uitleggen

[Freezerator]

c70070540 schreef op dinsdag 21 augustus 2007 @ 15:21:
[...]

Veelal is er meer te halen uit optimalisatie van indexen en queries dan uit extra schijven. Maar dat wil niet zeggen dat dat hier ook het geval is.

Heb je volledig gelijk in, maar zoals je zelf hierboven ook al kon zien was dat niet mogelijk. Ik verbaasde me zelf ook al over het aantal queries dat wordt uitgevoerd.

[Koffie]

Met bovenstaande. Post eens even wat exacte info.
Wat is je server OS ? Wat voor DB server software draai je exact ? Hoe groot is je DB ? Kun je logging raadplegen van je DB server ?
Wat zegt je leverancier ervan ? Wat voor config zijn de schijf / schijven ?

[Gé Brander]

Het zou me niets verbazen als er een Express versie van MSSQL op draait waarbij er boven een 10 tal connecties de performance dramatisch instort. Dan geldt ook de maximale database grootte van 4Gb.