The purpose of Cloud Linux is to improve the overall stability, reliability and performance of a shared server. Cloud Linux limits each individual account to a set amount of CPU and memory (RAM) resources. This means that rather than a server going under load and becoming slow for all users on it, only the account causing problems will be restricted. As Cloud Linux is becoming more common on shared hosting servers, it is important to know how to troubleshoot common problems that come up when using it to get the most out of your website and hosting environment.
I’ve used Cloud Linux for over a year now and think it’s great when used correctly, this article includes everything I have learned while using it during that time. A lot of users don’t like it because they have experienced it cutting the performance of their websites. With this guide you will be able to pin point issues and then work on resolving them. Although this information is aimed towards the server administrator, users within the Cloud Linux environment will find useful information for checking logs to find problems with their websites.
This article will be focused around cPanel, however most of the main points about Cloud Linux will still be directly useful for other control panels, such as Plesk.
The server I am running Cloud Linux on in my examples was running CentOS 5.8. It has 4 CPU cores and 4gb of RAM, this is taken into account later when going through limits.
How Cloud Linux limitations actually work
Before being able to identify issues you need to know how Cloud Linux actually works. Limitations can primarily be broken down into memory limitations and CPU limitations.
The memory limitations:
Cloud Linux places limits on virtual memory, not physical memory. While a server may have 4gb of physical RAM on it, the amount of virtual memory the server can provide is much higher. This means that a PHP script that reports using 200mb of memory may only be using 20mb of physical memory for example.
Have a look at the below image taken from a test server, namely the VIRT and RES columns, then see the information from the ‘top’ manual page below.
Alright so now we get a bit technical, the important thing to note is that basically VIRT is virtual memory (what Cloud Linux limits by) and RES is physical memory, which is what actually uses the RAM on the server – and no available RAM can turn into load problems as things start to swap to disk. As long as you have that concept under control, feel free to skip the snippet below.
VIRT: The total amount of virtual memory used by the task.
It includes all code, data and shared libraries plus pages that have been swapped out.
VIRT = SWAP + RES.
RES: Resident size (kb) The non-swapped physical memory a task has used.
RES = CODE + DATA.
SWAP: Swapped size (kb) The swapped out portion of a tasks total virtual memory image.
CODE: Code size (kb) The amount of physical memory devoted to executable code.
DATA: Data+Stack size (kb) The amount of physical memory devoted to other than executable code.
In the above top image we can see that the ‘user’ user is running a few PHP scripts using about 230mb of virtual memory per script, the physical amount of RAM used on the server is about 20mb per script or so – much lower. As long as the total virtual memory they are using running under that user is below it’s defined limit, there will be no problems.
The CPU limitations:
Cloud Linux places limits on total CPU being used as a percentage and it is done in a rather confusing way.
This limit sets the % of CPU being used relating to total number of CPU cores available on the server. This means that setting a 5% limit on an 8 core server will mean that each cPanel account can use up to 40% CPU of a single core. on a 4 core server a 5% CPU limit would mean 20% of a single core.
Here are a few examples of this:
15% limit on a 4 CPU core server = 60% of a single core
10% limit on a 4 CPU core server = 40% of a single core
15% limit on a 2 CPU core server = 30% of a single core
10% limit on a 2 CPU core server = 20% of a single core
This also means that setting an account to 25% CPU on a 4 CPU core server means that it can use an entire CPU core to itself – possibly too much for a shared hosting account, you may need to look into a VPS if you require this or more. If you set a limit 25% or higher in this instance, it wont make any difference as an entire core is already being allowed for the limit.
This is calculated as follows:
(1 core x 100)/total cores = maximum percentage.
There are further examples posted in the Cloud Linux documentation here.
You can set the amount of CPU cores used for an account, the server default is 1. Allowing an account to use more than 1 CPU core causes an overhead with Cloud Linux meaning it will use more resources so keep that in mind. If you change the amount of CPU cores per account you will need to restart the server.
In my experience users have more noticeable problems with memory limits rather than CPU limits. You will need to tune these depending on the hardware specifications of the server and resource usage of your users. You can provide decent performance for most normal users while still preventing servers going under load and causing problems for everyone on the entire server. With Cloud Linux only the user creating the problem is affected.
At the time of writing, Cloud Linux does not implement IO limits in my version which is 5 (unless in beta). Recently IO limits for Cloud Linux 6 were released to production so it will be interesting to see how this contributes to server usage in the future. It will definitely be good in allowing shared servers that still use traditional hard disks to have less access time for content, as high resource users will be denied complete server resource domination.
Managing Cloud Linux settings
You can manage Cloud Linux using the LVE (Lightweight Virtual Environment) Manager through WHM, just search for “CloudLinux LVE Manager”. This provides a GUI interface, you can of course manage things through the command line if you prefer. When you first enter the LVE Manager you’ll be on the home tab, you will see a list of current users using resources on the server at the time the page is loaded. Note that a new version of the LVE manager was released less than a week ago with a new interface, it still has the same basic functionality however but has the ability for you to apply limitations on different packages.
There are 4 other tabs here used to manage Cloud Linux:
Edit Default Settings: This is used to edit the settings for the WHOLE server. You can see what the current server limits are by checking here.
Edit Settings For Specific LVE: This is used to edit the limits on a specific account. You just need to find a cPanel accounts username, place it into the username field and then set the limits and save. Limits should typically only be increased after investigation of any current issues with the account, it’s best to solve the root cause than just delegate more resources.
Stats: Clicking stats will make a new interface appear and will let you find useful statistics about usage for an LVE
History: The History function is extremely useful, you can look at past usage of an account to identify when issues occurred as you can see how many resources have been used. This then gives you times to check logs for problems.
Before you can identify problems you need to know what all the variables mean in the statistics that you’ll be investigating. A good way to start investigating a potential Cloud Linux issue is to check the history and see what a user has been using as shown above with the history tab – this will bring up something like the image below. This was pulled from WHM, however a user can view similar graphs and data on their account through cPanel.
Now that we have all this information on a user account, what does it all mean?
||The time period the information is from
||Average CPU usage (as a percentage out of 100%)
||Max CPU usage (as a percentage out of 100%)
||CPU Limit (always 100% – 100% of what ever limit in place)
||Average Entry Processes
||Max Entry Processes
||maxEntryProc limit (concurrent processes, limited to 20 (default))
||Average memory that has been used
||Maximum memory that has been used
||Memory limit assigned to the account
||Out Of Memory Faults
||Max Entry processes faults