Skip to main content

Let me know if you are running BP Prod SQL Server in ESX VM.   


I read some strange (non-BP) SQL Server performance issues while running under VM elsewhere (SQLIO benched fine).


We'll have growing number of processes (18, growing about 4 a year).


I am thinking 16gb memory with quad core CPU to start with for the physical server.


Haven't verified this claim:


http://www.sqlsolutions.com/articles/articles/SQL_Server_and_VMware-A_Potentially_Fatal_Combination.htm


K2 Support Sent this:






1024x768



Normal
0




false
false
false

EN-US
X-NONE
X-NONE










































































































































































http://help.k2.com/en/KB000432.aspx

VMWare's best practices is usually to utilize physical disks vs virtual disks for SQL databases.  However with that being said, I have seen some customers with production servers in VMWare ESX environments.  Note that they were running on pretty powerful hardware to achieve the load they had (about 2000+ process instances a day).  They had dedicated dual quad core (HT) blades and also dedicated RAID LUNs on the SAN for the K2 databases.


This dual core blade they have is just running 1 VM under ESX hosting K2 server right?


The reason I would do this is to provide protection against hardware failure but reduce complexity of setting up a failover cluster (additional two sets of servers - one in DR site) just standing by.


As far as I recall, they have a 2 node K2 farm with a dedicated SQL server for the K2 databases (I can't remember if it was a cluster or stand alone setup). I wouldn't recommend putting SQL server with K2 or any other application components as per MS best practices.  SQL server usually sucks up a lot of memory for performance caching.  Complicated SQL queries can also spike the I/O and CPU loads which can cause performance problems for other services.  I would only put it on the same box if the transaction load isn't too high.


However, the best performance indicator is usually the actual experience.  If OS response is sluggish (try comparing OS boot times) and/or accessing the workspace worklist and reports is slow, it normally indicates some performance issue with the VM setup.


So this should do it...  4 vCPU and 12GB RAM in ESX 4 with RDM (physical disk) on its own LUN.  


This is 6 times more memory than is allocated on K2 .NET 2003 (not in VM).


 


That sounds reasonable.


I think probably the comparison to K2.net 2003 probably is like comparing apples to oranges.  The underlying platform has changed significantly (SQL 2005 to SQL 2008 and Win2K3 to Win2K8 R2).


Especially for the K2 component, we have a ton of new stuff in K2 blackpearl which didn't exists in K2.net 2003 and the underlying architecture has also improved/changed a lot.


Reply