144

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?
Improve this question

4 Answers 4

Reset to default
109

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 efficiently.

Some Capacity Planning Axioms

  1. RAM is cheap
    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
    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
    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.
  4. Electricity is expensive
    Even though RAM and disks have decreased in price considerably, the cost of electricity has gone up steadily. All those extra disks and RAM, not to mention CPU power, will increase your electricity bill (or the bill you pay to your provider). Plan accordingly.
Improve this answer
6
  • 2
    You should totally drop that and use integration by parts!
    – Gilles 'SO- stop being evil'
    Commented May 28, 2013 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
    Commented May 28, 2013 at 23:03
  • 33
    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
    Commented Jun 11, 2014 at 10:52
  • 2
    In mid-2019 nobody should be buying spindle drives anymore.
    – Robert Harvey
    Commented May 8, 2019 at 17:49
  • 1
    I'd like to add one important planning point: assume that you'll get hostile connections. If you want to run a website and do not mind about FISA letters, CloudFlare is your friend. Otherwise, you'll be paying a lot or be vulnerable. Never ever assume that not upgrading your internet facing OS is okay. Never ever assume that some magic firewall will protect your vulnerable OS.
    – Mikko Rantalainen
    Commented Jun 24, 2019 at 11:50
50

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 kind of 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 its 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 seven 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 a 1.8 GHz CPU may be 64.8 GHz of CPU on a host, but no single thread will run faster than 1.8 GHz.
  • 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!

Improve this answer
3
  • above all else, do use vm based systems on two separate physical servers with unbound vm's. this allows for hardware failure without loss of the entire system. vm's can move between identical servers without loss of data. just sessions get lost, then rebuilt. personally, i would outsource to a hosting company that offers these services (google or amazon). they are expensive but a lot less than running your own.
    – Random-IT
    Commented Mar 19, 2015 at 16:07
  • 4
    The thing that I've seen undersized most often in VM implementations is disk I/O. Most people understand disk space, CPU speed, and memory. They forget about that disk performance.
    – Dan Pritts
    Commented Feb 19, 2016 at 17:31
  • @danpritts Unfortunately, you are not wrong.
    – dimitri.p
    Commented Oct 2, 2022 at 22:08
9

Make sure you're asking the right question.

  • Computers are cheap
  • Future needs are very hard to predict
  • Plan how to scale, not what to buy ahead of time

If you don't know what you'll need, that implies you don't need very much. If you have a hot web site, you also probably also have an operations team who knows how much ram, disk, io, network etc... your app needs. If you're in the dreaming stage, you should start with your desktop and work your way up.

Make sure you have some idea how you're going to scale when things get bigger. Can you add more servers behind the load balancer? Can you shard the redis server?

Also, having your own data center sucks. A data center (even if it's just one computer) is a distraction from your actual purpose. You can not just buy a computer, turn it on, and walk away. You need air conditioning, air filtration, reliable power, reliable internet, backups, spare parts, physical room to grow, power capacity to grow, power cables that don't get tripped on and a zillion other headaches.

Improve this answer
1

Start with estimating "queries per second". 100 ie easy to handle. 1000 may be an issue. 1 million is virtually impossible on a single machine.

"Number of users" -- Thousands of users not doing much is less trouble than one user predicting tomorrow's weather.

"Bandwidth" -- How many bytes need to be shoveled into/out of the server? How much data will you have on disk?

"Social networking" -- Build a prototype, get a thousand users, and gather metrics. Then let's discuss how you should rewrite the schema and redesign the server topology.

"Sharding", "Caching", etc. When you get to a million "users", you may need the data and activity split among a hundred servers. Without more details, we cannot discuss how to do the split. Furthermore, it is really premature to design for scale until you discover what brick walls you are going to hit.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .