VMWare tips/ SQL & NAV

borgy

Beste mensen,

We hebben Nav 6.0 nu op VMware (x64) staan voor 180 - 200 gebruikers.
Nav wordt mede geraapleegd via een 2 portals (klant/klantenservice) via webservices -> die weer communiceren met NASSen en views
Dan hebben we nog een koppeling met een digitaal factureringssysteem en een planningsapplicatie.
13 financiele bedrijven waaraan het factureringssysteem is gekoppeld.

Specs 8 2.20 ghz processoren, 16 gig memory, Windows Server x64 Enterprise, SQL Server 2008 R2 x64 Enterprise

Ik heb de Max Mem option op 11900 gezet omdat je de externe SQL (dll) processen ook nog ruimte moet geven.
We kregen te maken met veel Page IO latch_SH en suspended processen, het geheugen werd continu tot zijn max bereikt.

Nu mijn vraag, wanneer ik geheugen heb weet ik wel hoe ik dit het beste kan tunen, monitoren. Echter zijn er ook best practises of ervaringen met SQL op VMware?
Ik weet bijv. dat Microsoft het niet aanbeveelt tenzij je de hardware aanzienlijk aanpast. Dat hebben we inmiddels gedaan met 8 gig extra (nu 24 gig) en dit weer gefinetuned volgens het aantal threads * size (platform).
Tevens zijn er nog wat fine tune opties voor de db, die wil ik vanavond inrichten.

Echter ik weet niet waar het ophoudt, hij gebruikt z'n max nu weer en mogelijk keren de Page_IO_Latches ook weer terug. Dat hoeft niet perse, maar ik zou graag wat meer zekerheid hebben, bijv. ervaringen uit de praktijk met VMware. Misschien een organisatie met gelijke hoeveelheid gebruikers. Of hoe kun je erachter komen hoeveel geheugen hij max ongeveer nodig heeft met het aantal genoemde gebruikers en services.

Ik ben benieuwd naar jullie ervaringen.

kriki

Ik kan je wat links geven met materiaal dat ik over de jaren gevonden heb:

http://www.yellow-bricks.com/2010/04/08/aligning-your-vms-virtual-harddisks/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+passvvc+%28PASS+Virtualization+Virtual+Chapter%29
http://www.mibuso.com/forum/viewtopic.php?p=162516
http://itknowledgeexchange.techtarget.com/sql-server/vmware-and-sql-and-lock-pages-in-memory/
http://blogs.technet.com/b/andrew/archive/2009/10/16/virtualisation-for-the-dba-part-1-are-you-bovvered.aspx
http://blogs.technet.com/andrew/archive/2009/10/12/virtualisation-for-the-dba-part-2-sql-server-management.aspx
http://blogs.technet.com/andrew/archive/2009/10/20/virtualisation-for-the-dba-part-3-sql-server-performance.aspx
http://blogs.technet.com/andrew/archive/2009/10/21/virtualisation-for-the-dba-part-4-licensing-and-support.aspx
http://blogs.msdn.com/b/boduff/archive/2010/03/31/general-guidance-for-sql-server-on-virtualisation.aspx
http://blogs.msdn.com/b/cindygross/archive/2009/10/23/considerations-for-installing-sql-server-on-vmware.aspx
http://matthensley.wordpress.com/2010/05/16/best-practices-and-considerations-for-virtualizing-microsoft-sql-server-on-vmware/
http://sqlblog.com/blogs/jonathan_kehayias/archive/2010/11/22/virtualizing-sql-on-vmware-reference-list.aspx
http://www.brentozar.com/archive/2011/05/keys-deploying-sql-server-on-vmware/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BrentOzar-SqlServerDba+%28Brent+Ozar+-+SQL+Server+DBA%29
http://www.sqlservercentral.com/articles/Virtualization/73815/
http://blogs.technet.com/b/andrew/archive/2011/05/18/virtualising-sql-server-a-second-opinion.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+technet%2FDeepFat+%28Insufficient+Data%29

Marije_Brummel

Belangrijkste is eigenlijk dat op de disks die je voor de SQL DB gebruikt geen andere VM processen draaien die voor vertraging zorgen. Dat neemt de belangrijkste bottleneck wel weg.

Heb je al gekeken naar de queries via de profiler?

Het kan ook de connectie zijn tussen het schijvenkabinet en de server maar dat lijkt me stug.

Wellicht een view die meerdere tabellen samenvoegd uit bedrijven? Dat is altijd killing voor je I/O

borgy

@Kriki,

Dank voor het leesvoer, daar zitten zeker tips in voor het tunen van VMware en SQL server.

@Mark

Dat schijvenkabinet is een zeker een optie, systeembeheer werkte met ISCSI SAN en een interne disk en laat die ene database nou net op de interne disk staan.
Tevens is de ISCSI SAN nog de oude inrichting het kan ook zijn dat ze bij storage nu alleen VM storage aanbieden.
Dank voor de tip.

Voor zover ik in de profiler en in de activity monitor kan zien heeft hij het niet moeilijker met de views dan andere processen.
De views ken ik ook aardig en ze zijn echt ingericht per proces en per bedrijf dus daar verwacht ik geen bottleneck, maar ik zal dat zeker even meenemen.

Beide dank!

Groet André