Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Multiple instances on a VM Expand / Collapse
Posted Monday, June 9, 2014 9:46 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, November 17, 2016 11:57 AM
Points: 1,043, Visits: 8,023
We're trying to decide if we should use a single large instance of SQL Server or multiple instances on the same server. This is for a dev environment.
So far, I have these things to watch out for:
Have to limit max RAM per instance so no instance grabs it all
There will be I/O contention and CPU contention between instances since the different instances won't coordinate with each other.
It limits the available RAM for In-Memory tables
It sets lower limits to the amount of RAM available for any given query, causing artificial "contention" even when there's nothing else running at the time.

Anything I'm missing?

Anyone have strong feelings for or against?

When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Post #1578891
Posted Tuesday, June 10, 2014 6:50 AM

SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 12:45 PM
Points: 801, Visits: 8,186
Most of what you are describing are performance related considerations.
Less resources may not be a bad thing in some cases.
Tuning / load testing would likely be something done in an environment that may more closely mirror production.
Multiple Dev environments would tend to isolate work of developers, which could offer some advantages if a restore is needed.

So if just Dev / Prod, your considerations may be a bit different than if you have QA processes in between.
Post #1579163
Posted Tuesday, June 10, 2014 4:05 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, November 4, 2016 10:42 AM
Points: 3,243, Visits: 2,467
Do not 'over provision' - SQL does not like having memory and/or CPUs managed in and out.

Most applications can handle that but SQL Server really, really hates it.

In looking at one huge instance vs many smaller ones I would ask myself the following:
- can we take all of development down in one huge instance for patching
would it make sense to stagger the patching outages so not all of development is down at once

The more important question is licensing costs.

With one huge instance you could either license the entire ESX cluster by CPU pairs or the huge SQL instance by CPU pairs.
I am referring to SQL 'enterprise' edition - 20+ processors and 128 GB RAM on each (even a small ESX host has a couple of HP DL-380s with 2x12 CPU configurations) a total of 48 processors to license. That is 24 - 2 packs at about 16.5k per 2 pack or roughly $800,000.

Now if you had smaller instances with SQL 'standard' edition, the 2 pack licensing cost goes down to 3.6k or $173,000.
However you can only V-motion once every 90 days under the 'standard’ edition – 4 - 12 CPU and 64 GB RAM instances would fit.

Even more economical, since this is development, put developer 'edition' on there for $50. However each and every developer would need an MSDN Developer license - they start at about $650 and go all the way to about 3K. So if it is pure development, say you had 50 developers and you got them all average MSDN licenses for about 1 K per you'd be out roughly $50,000.

Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #1579434
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse