Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a Canonical Question about Capacity Planning

Related:

I have a question regarding capacity planning. Can the Server Fault community please help with the following:


  • What kind of server do I need to handle some number of users?
  • How many users can a server with some specifications handle?
  • Will some server configuration be fast enough for my use case?
  • I'm building a social networking site - what kind of hardware do I need?
  • How much bandwidth do I need for some project?
  • How much bandwidth will some number of users use in some application?
share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

2 Answers 2

up vote 47 down vote accepted

The Server Fault community generally can't help you with capacity planning - the best answer we can offer is "Benchmark your code on hardware similar to what you'll be using in production, identify any bottlenecks, then determine how much of a workload your current hardware can handle, and/or how much hardware horsepower you need to handle your target workload".


There are a number of factors at play in capacity planning which we can't adequately assess on a Question and Answer site:

  • The requirements of your particular code/software
  • External resources (databases, other software/sites/servers)
  • Your workload (peak, average, queueing)
  • The business value of performance (cost/benefit analysis)
  • The performance expectations of your users
  • Any service level agreements/contractual obligations you may have

Doing a proper analysis on these factors, and others, is beyond the scope of a simple question-and-answer site: They require detailed knowledge about your environment and requirements which only your team (or an adequately-compensated consultant) can gather effeciently.


Some Capacity Planning Axioms

  1. RAM is cheap
    Corollary: If you expect your application to use a lot of RAM you should put in as much RAM as you can afford / fit.
  2. Disk is cheap
    Corollary: If you expect to use a lot of disk you should buy big drives - lots of them.
    SAN/NAS storage is less cheap, and should also usually be spec'd large rather than small to avoid costly upgrades later.
  3. Workloads grow over time
    Corollary: Assume your resource needs will increase.
    Bear in mind that the increase may not be symmetrical (CPU and RAM may rise faster than disk), and it may not be linear...
share|improve this answer
    
You should totally drop that and use integration by parts! –  Gilles May 28 '13 at 19:13
    
+1. And RAM, as you suggest in axiom #1, is one of those things that has massive benefits. For instance, it increases your ability to better utilize caching, which in turn allows you to make fewer database queries, which in turn lightens the load on the disk and CPU. I'm often frustrated by hosting providers that offer a fast CPU with their servers and a minimal amount of RAM. –  Steve Wortham May 28 '13 at 23:03
4  
I'd add to this: Disk capacity is cheap. Disk performance gets expensive. Especially as we see a growth in disk sizes over 10 yearrs, but the laws of physics haven't changed. Rule of thumb I use (as of today; June 2014) is that for optimal performance: 75 IOPs per spindle on SATA, 200 IOPs per spindle on FC, and 1500 IOPs per SSD. Big SATA drives give really quite poor IO per gigabyte ratios. –  Sobrique Jun 11 at 10:52

Virtual Machine Count planning

When it comes to figuring out how many VMs you should plan for on a single host, there are actually no really good rules of thumb. In fact, there is only one, and it is only kinda good:

Virtual-Machine counts are usually bounded by RAM, except for when they're not.

Which isn't terribly helpful. If those VMs are going to be running low-CPU applications, then your limiter is going to be based on RAM. Each VM platform has it's own abilities to oversubscribe RAM, so it isn't as easy as TOTAL_RAM / Per-VM-Ram = MachineCount, but that number is a good planning item.

But what if your VMs are doing things besides low-CPU packet-slinging?


Virtual-machine counts are bounded by 7 discrete resources available to the host machine:

  • Hypervisor VMware, Xen, HyperV, KVM, whatever. Each has their own count-impacting features. Some are very good at memory-page deduplication, others not so much. Some don't permit oversubscription of CPU capacity, some do.
  • CPU Core Speed This limits the maximum single-threaded performance a VM will be able to run. 36 cores of 1.8GHz CPU may be 64.8GHz of CPU on a host, but no single thread will run faster than 1.8GHz.
  • CPU Core Count This, with core-speed, describes the ceiling of maximal CPU performance you can experience.
  • System RAM As described above, this limits the number of VMs you can run. Certain hypervisors are better than others at things like memory-page deduplication, so if you're running 100 identical VMs you can pack a lot more of these on such deduplicating systems than if you were running 100 completely different VMs.
  • Disk Size Each OS image takes a certain amount of space. You need enough space to store it all. Therefore, disk-size puts an upper limit on how many VMs you can host.
  • I/O Bandwidth The disk underlying the VMs has a maximum on how many I/Os per second it can handle. If you throw too much at it, systems will bog down waiting for the I/O to complete. This puts an upper limit on how many I/O consuming VMs you can run.
  • Network Bandwidth For network-using VMs, the available network bandwidth will put a ceiling on how many such VMs you can run on a given host.

All of these can be the thing you trip over, it all depends on what you're doing with your VMs. Some things to remember:

  • There is no such thing as a generic system.
  • There is no such thing as a generic web-server, since application code can run from barely-moves-the-needle CDN-style serving, to big deep-crack stuff like video transcoding.
  • There is no such thing as a generic database server. These can run from tiny systems used just for session-state-tracking, to very big ones.

To figure out how many VMs you can pack into a host-system, you need to know how your systems run and what they require to run well. Once you know that, you can then do the count-planning. And better yet, figure out how beefy you need to make your host-systems!

share|improve this answer

protected by voretaq7 Apr 30 '12 at 19:20

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.