SQL Server 2008 - Upgraden, Load Balancing of iets anders?

[DennusB]

Goedemiddag Tweakers,

Ik zit met een vraag, en na een paar uur googlen ben ik er nog steeds niet uit wat nou de meest verstandige optie is.
We draaien hier sinds een jaar Exact Globe. Dit leunt voor de volle 100% op SQL Server, en daarom hebben we begin dit jaar 2 HP DL120 G6 servers aangeschaft met RAID controllers, 15k schijven en 8GB RAM.
Toen we dit jaar begonnen met Exact was de database ongeveer 3GB, prima. Nu, na 11 maanden is de database al dik 9GB, en gaan we richting de 10GB.

De servers staan in Master - Slave opstelling. De SQL Database word constant gerepliceerd naar de 2e server, maar heeft geen automatic failover. Nu is het probleem eigenlijk dat we met de 8GB geheugen niet meer genoeg hebben. Het RAM zit voor 99% vol, en ook na een reboot zit ie gelijk op dik 90%.
Nu kunnen we natuurlijk het RAM upgraden(max 16GB) maar ik vraag me af hoelang we het met 16GB kunnen uitzingen?
Nu kwam mijn hoofd opeens met het idee om 2 servers Master-Master in te zetten en gewoon te werken met load balancing. Helaas blijkt SQL Server 2008 R2 dit niet te ondersteunen, dus ook dit is geen optie.

Nu is mijn vraag dus, is er iemand die hier even zijn/haar licht op kan laten schijnen? Ik wil voor lange termijn gewoon een goede oplossing. En niet iets waardoor over een jaar het hele server-park weer op de schop mag.
Ik hoop dat iemand me even kan helpen

[Verwijderd]

Is een cluster aanmaken met de servers niet een mogelijkheid? Alle load wordt dan verdeeld over de twee servers.

[Craven]

Dat je geheugengebruik direct na boot op 90% zit zegt vrij weinig bij sql. sql pakt net zoals exchange zo ongeveer alles wat ie pakken kan en laat een klein beetje over. Weet je zeker dat alles aan zijn max zit?

[_Arthur]

DennusB schreef op dinsdag 07 december 2010 @ 12:46:
Nu is het probleem eigenlijk dat we met de 8GB geheugen niet meer genoeg hebben. Het RAM zit voor 99% vol, en ook na een reboot zit ie gelijk op dik 90%.

Is het dit enige probleem of zijn er ook performance issues?

[PolarBear]

DennusB schreef op dinsdag 07 december 2010 @ 12:46:
We draaien hier sinds een jaar Exact Globe. Dit leunt voor de volle 100% op SQL Server, en daarom hebben we begin dit jaar 2 HP DL120 G6 servers aangeschaft met RAID controllers, 15k schijven en 8GB RAM.
Toen we dit jaar begonnen met Exact was de database ongeveer 3GB, prima. Nu, na 11 maanden is de database al dik 9GB, en gaan we richting de 10GB.

Tenzij er heel brakke queries worden gebruikt stelt dat helemaal niets voor.Groote van een database ansich is sowieso geen enkele indicator voor performance problemen.

De servers staan in Master - Slave opstelling. De SQL Database word constant gerepliceerd naar de 2e server, maar heeft geen automatic failover.

Verdiep je alsjeblieft even in de HA mogelijkheden van SQL server. Qua performance gaat clustering je over het algemeen niet helpen.

Nu is het probleem eigenlijk dat we met de 8GB geheugen niet meer genoeg hebben. Het RAM zit voor 99% vol, en ook na een reboot zit ie gelijk op dik 90%.
Nu kunnen we natuurlijk het RAM upgraden(max 16GB) maar ik vraag me af hoelang we het met 16GB kunnen uitzingen?

Ook het geheugengebruik is geen enkele indicatie van een performance probleem. SQL server gaat zoveel mogelijk geheugen gebruiken, altijd. SQL server is namelijk standaard zo geconfigureerd om maximaal te performen. Als je denkt dat het een probleem is dat SQL Server al je geheugen gebruikt heb je het niet begrepen (en dan nog wat het je aan ongebruikt geheugen?)

Wat wel belangrijk is voor je perfomance (zie ook hier):
- Hoe is de diskconfiguratie;
- Hoe en welke indexen worden gebruikt;

Loadbalancing gaat jouw probleem ongeloofelijk veel moeilijker maken (SQL loadbalancing/clustering/HA is niet zo maar wat, daar heb je een echte DBA'er voor nodig). Overigens kan ik mij niet voorstellen dat je een echt probleem hebt.

[ Voor 8% gewijzigd door PolarBear op 07-12-2010 16:32 ]

[mieJas]

Als er geen andere databanken op die server staan en er niet meer dan 50 gebruikers tegelijk op werken, zou ik me geen zorgen maken.

[DigiK-oz]

Is je applicatie ook daadwerkelijk traag, of staar je je alleen maar blind op het feit dat je server al zijn memory gebruikt?

Zoals al gezegd, SQL Server pakt zo veel mogelijk memory (tenzij je het anders configureert) voor caching e.d. Als je applicatie dus gewoon goed performed, is er gewoon geen probleem. Is je performance slecht, ga dan eerst eens kijken naar de queries/indexing etc.

Bottom line : Als je de server gaat upgraden naar 16GB, zal SQL Server vrijwel zeker weer 90% daarvan pakken. En dan denk jij nog steeds een probleem te hebben. Dus dan maar naar 32 GB....etc

En inderdaad, een database van die grootte is peanuts, tenzij de queries/indexen brak zijn en je allemaal full scans hebt.

[ Voor 4% gewijzigd door DigiK-oz op 07-12-2010 17:01 ]

[GSamson]

Je spreekt over Master - Slave maar die terminologie bestaat helemaal niet in SQL Server. Heb je het dan over:
- SQL Server replicatie
of
- Database Mirroring

Replicatie is geen goede oplossing voor HA. Database Mirroring is een zeer geschikte oplossing. Een cluster is complex (als je het goed wil doen) en daar heb je ook shared storage voor nodig. DBM is the way to go.

De grootte van de database is hier inderdaad het probleem zeker niet. 10 GB is "niets".

Een SQL Server Best Practice is het limiteren van je geheugenverbruik. Stel SQL Server in om 6GB memory te gebruiken. Je hebt namelijk nog altijd geheugen nodig voor het OS en client connections.

En zoals hierboven reeds gevraagd, is de applicatie - nadat je de memory limiet ingesteld hebt - in de praktijk traag?

[GSamson]

De instelling om het geheugen te beperken, vind je trouwens gewoon terug in de properties van de SQL Server instance.

[PolarBear]

DigiK-oz schreef op dinsdag 07 december 2010 @ 16:59:
Bottom line : Als je de server gaat upgraden naar 16GB, zal SQL Server vrijwel zeker weer 90% daarvan pakken. En dan denk jij nog steeds een probleem te hebben. Dus dan maar naar 32 GB....etc

Ik vraag mij of of er überhaupt een probleem is. En gezien zijn database grootte zal er eerder een I/O probleem zijn (logs en data files gescheiden?)

GSamson schreef op dinsdag 07 december 2010 @ 17:31:
Een SQL Server Best Practice is het limiteren van je geheugenverbruik. Stel SQL Server in om 6GB memory te gebruiken. Je hebt namelijk nog altijd geheugen nodig voor het OS en client connections.

Sorry maar deze Best Practice ken ik niet. Ik zou ook niet weten waarom je dit zou doen. Het memory management van Windows en SQL Server kan prima verzorgen dat er genoeg geheugen is voor het OS en de client connections. Zeker het SQL Server memory management is dermate intelligent dat ik nooit op een dedicated SQL server geheugen zou willen beperken. Sterker:

SQL Server dynamically acquires and frees memory as required. Typically, an administrator does not have to specify how much memory should be allocated to SQL Server, although the option still exists and is required in some environments.

Meer info over SQL Server memory management is onder andere hier (wel SQL 2000, maar het is alleen maar beter geworden) en hier:

The default memory management behavior of the Microsoft SQL Server Database Engine is to acquire as much memory as it needs without creating a memory shortage on the system. The Database Engine does this by using the Memory Notification APIs in Microsoft Windows.

[..]

As other applications are started on a computer running an instance of SQL Server, they consume memory and the amount of free physical memory drops below the SQL Server target. The instance of SQL Server adjusts its memory consumption. If another application is stopped and more memory becomes available, the instance of SQL Server increases the size of its memory allocation. SQL Server can free and acquire several megabytes of memory each second, allowing it to quickly adjust to memory allocation changes.

Zie overigens hier voor diverse MS best practices.

Bottomline, misschien kan je door meer ijzer de performance verbeteren (als dat al een probleem is) maar ik kan mij niet voorstellen dat het ook maar in de verste verte nodig is.

[ Voor 6% gewijzigd door PolarBear op 07-12-2010 19:01 ]

[GSamson]

PolarBear schreef op dinsdag 07 december 2010 @ 18:59:
[...]

Sorry maar deze Best Practice ken ik niet. Ik zou ook niet weten waarom je dit zou doen. Het memory management van Windows en SQL Server kan prima verzorgen dat er genoeg geheugen is voor het OS en de client connections. Zeker het SQL Server memory management is dermate intelligent dat ik nooit op een dedicated SQL server geheugen zou willen beperken.l]:

[...]
.

So it seems. My mistake.. Altijd fijn om bij te leren. Enkel echt nuttig wanneer er eventueel nog andere zaken op draaien.

Nu is de belangrijkste vraag nog: is er in feite een probleem? De topicstarter vermeldt nergens een performance probleem. Enkel maar dat alle geheugen aangesproken wordt maar dit kan wellicht beschouwd worden als een non-issue.

[axis]

Je kunt ook eens een trial van Spotlight on SQL Server Enterprise downloaden en op een andere machine installeren, en dan je SQL server laten monitoren. Die maakt op een simpele manier een heeeeleboel performance counters makkelijk inzichtelijk, en interpreteert ook een aantal counters voor je.

[Oogje]

Ik sluit me helemaal aan bij PolarBear.
Heeft TS uberhaupt een probleem?