Memory and CPU requirements

In most cases, initial system sizings are done with the assistance of IBM®, your business partner, or consultant. This section gives you an appreciation for the things considered during an initial sizing and the things you should consider as you add work to your system.

To get you started, this topic gives you some basic knowledge about estimating the memory and CPU requirements for your Linux® virtual servers. Such estimating is not an exact science and your experience might vary, but following the guidelines in this topic should help you get started, after which you need to measure the performance and fine tune your system. Topics in Monitoring performance and capacity help you fine-tune your initial configuration.

Overview of estimating memory and CPU requirements

Memory and CPU requirements fall into two categories:

Real memory and CPU
Memory and CPU for virtual machines.

Memory for the LPAR

A key factor in determining memory resources is the memory required for your applications. If the applications are new, you must estimate or start at some initial size; you can determine existing application memory requirements if the applications are currently running on other platforms. For example, you might not know how much memory a new WebSphere® application requires, so you can start with 200 MB for the size of the Java™ Virtual Machine. Additionally, WebSphere Application Server requires 60 MB of memory.^¹ So the total for your new application would be 260 MB. If you have an existing WebSphere application you know requires 250 MB of memory, the total with WebSphere Application Server would be 310 MB.

Include in your estimate the memory requirements for z/VM itself. For information about estimating memory requirements for z/VM itself, see Host Storage Planning and Administration in z/VM: CP Planning and Administration.

The total memory requirement for your applications, plus memory required for each Linux operating system and z/VM itself, give you an estimate of the memory required for a given LPAR. Do not pad the total memory figure.

Many customers prefer to isolate their applications by running each one in a separate virtual machine. Another strategy is to combine more than one application in a virtual machine, keeping the number of Linux virtual servers to a minimum rather than creating one Linux virtual server for each application. The reason is that each Linux virtual server brings with it some overhead: each Linux operating system itself requires additional memory, and even an idle Linux virtual server uses some CPU resources. Also, applications sometimes can share middleware, which conserves memory. If it conforms to your installation's policy, you might be able to combine more than one application in a virtual machine, thereby saving memory. For example, several WebSphere applications can share the same WebSphere Application Server and the JVM in one virtual machine rather than each application having its own WebSphere Application Server and JVM in its own virtual machine, which would multiply the number of virtual machines and require more total memory.

During system operations, measure actual memory usage to test the initial memory allocation, which assumes all your virtual servers need the estimated amount of memory all the time. Just as CPU demand has peaks and valleys, so does memory usage.

Memory for the virtual machines

For the general case of server consolidation, keep the virtual machine size small. How small you can define the virtual machine depends on the applications and workloads running in those virtual machines. Various Linux distributions might have minimum requirements as low as 64 MB. Some applications run fine in those minimum configurations. Other applications and workloads might require larger virtual machines. Avoid defining a virtual machine larger than it needs to be, because Linux uses excess memory for file and buffer caches. On a stand-alone system, these buffers can be very helpful for certain workloads to avoid I/O. However, in a virtual environment, the extra memory consumed adds to overall system memory contention. Such cases could cause a negative impact greater than the positive impact of I/O avoidance, which is especially true in configurations in which data is shared heavily between virtual servers and is mostly read. In those configurations, z/VM minidisk caching can help avoid I/O. As a general guideline, define the virtual machine memory size to keep Linux on the verge of swapping. Lower the memory size until you see Linux begin to swap, then increase the virtual machine memory to the next bigger size.

Another way to reduce the memory requirements is through discontiguous saved segments (DCSS). A DCSS is an area of virtual storage outside the address range of a virtual machine. The area can contain read-only data or reentrant code. A DCSS connects discontiguous segments to a virtual machine’s address space so programs can be fetched. DCSS sizes can be above 2 GB and combined with Linux to form data areas that are greater than 2 GB in size. DCSSs can be shared by many virtual machines, so total virtual memory required might be reduced. This reduced requirement for virtual memory can:

Reduce CP paging requirements
Allow a given z/VM instance to support more Linux virtual machines
Reduce the amount of Linux disk I/O by having file systems, block devices, and shared objects in DCSSs.

Note: Shared storage within a DCSS can be reserved (using the SET RESERVED command) to ensure an expected amount of DCSS storage remains resident.

A Linux virtual server machine uses DCSSs through the DCSS block device driver.

Related information: The following are related sources of information.

This manual shows you how to set up a swap disk on a z/VM minidisk. Other options are available, such as using a virtual disk in storage and DCSS. For more information on swap disk options, see Linux Performance when running under VM.
For more information about DCSS block device drivers, see Linux on System z®: Device Drivers, Features, and Commands at: IBM developerWorks: Linux: Linux on System z: Documentation: Development Stream.

Real CPU requirements

The real CPU requirement is not simply a function of a single server: rather, the requirement is a function of all your virtual servers combined (see Overview of z/VM capacity planning). You must consider what each of your applications require and then estimate the overall CPU requirement. Consider the processor share each virtual server receives for satisfactory performance (see Steps for using CP commands to improve performance). Your IBM representative, business partner, or consultant offer services to help you perform this task.

When defining z/VM LPARs, typically assign a minimum of two logical processors (many middleware products advise that you use two logical processors). You have the option of dedicating the processors to the LPAR or sharing them with other LPARs. It is also possible to set different processing weights to LPARs, which gives more processor resources to one over another. For instance, you might entitle your production LPAR to 60% and your test LPAR to 40% of the processor resources. For details, consult the Processor Resource/Systems Manager Planning Guide for your IBM Z^(R) server.

Virtual CPU requirements

In general, follow this guideline: define as many virtual CPUs as needed (maximum CPU resources required), but do not exceed the number of real processors assigned to this LPAR. Extra virtual CPUs just add to the overhead and potentially increase the software multiprocessing factors.

If the Linux program cpuplugd is available, define the maximum number of virtual CPUs that a Linux server could use. cpuplugd can tailor the virtual CPUs actually used by the Linux server, and thus cause no additional CP overhead. If cpuplugd is not available, do not define more virtual CPUs than the Linux server is likely to use.