Sizing Guide

From Sun Ray User Group Wiki

Jump to: navigation, search
Sun Ray User Group Wiki - Navigation
General Sun Ray Information
General Sun Ray Information
General Sun Ray Information
Latest Sun Ray News
Latest Sun Ray News
Latest Sun Ray News
The Sun Ray Community
The Sun Ray Community
The Sun Ray Community
Sun Ray How To Section
Sun Ray How To Section
Sun Ray How To Section
Getting Support
Getting Support
Getting Support

Sizing Guides

Rob's Memory Based Sizing Guide

While most people think about the amount of CPUs required for a virtual desktop solution I prefer to approach sizing from a memory perspective because of three key issues:

  • For any Sun Ray deployment the cost of the servers is a key component. If you look at the cost of most servers these days the single most expensive component is memory (not CPUs).
  • When a Sun Ray environment hits 100% CPU usage there is a linear slowdown of the end user experience. However, when memory is exhausted and heavy swapping (disk I/O) occurs the performance impact is exponential.
  • It is easier to profile what average memory usage will be like than CPU usage.

Because of these three issues I like to size my machines first based on memory requirements and then on CPU requirements.

In a typical full desktop user environment (i.e. Gnome/Firefox/OpenOffice etc) the memory requirements will be around 256MB per user (or 4 users per GB). You can get some idea of memory usage per active user by setting up a pilot system. From the console check the memory used (I prefer "sar -r" for my memory information as it excludes disk caching). The start up one user and launch a few key apps and "sar -r" again.

This gives some idea of the memory allocation when a new user signs on. Of course some of that memory can easily be swapped out and never really used again but generally 80+% is needed in active pages. You can do this with multiple users and various combinations of applications. NB: Applications like Firefox will increase memory usage as you visit more pages as it caches information in memory. What you save in network bandwidth you lose in available memory!

In this type of environment my rule of thumb is that a balanced system will have a ratio of one CPU core for every 3GB of memory (or 12 users per CPU core). This rule of thumb is based on the assumptions that:

  • Runaway processes are well managed
  • Users are aware of the impact of flash animations on CPU consumption and do not generally leave their web browsers on flash intensive sites (i.e the company home page doesn't use flash!)
  • There are at least 4 CPU cores (so that any one bad process only kills 25% of the CPU resources
  • There are no obviously CPU intensive application being regularly used (compiling, lots of video, etc)

An example system is a Sun X4100 with 2 * Dual Core (4 cores) and 12GB of memory (approx 48 users) or a Dual CPU Quad Core (Barcelona etc) box with 24GB (approx 96 users).

If you are on a tight budget you can push the numbers of users per CPU up (and live with complaints of a consistently slow system) or if you have some a decent capital budget spend up large and increase CPUs and have a faster system. However, if you are cheap on memory you will get very inconsistent performance and from my experience users complain more on systems with inconsistent performance than those with consistently slow performance.

--Rgiltrap 12:42, 18 May 2007 (EEST)

Personal tools