Tuning a vServer/VPS for performance

vServers are virtual "stand-alone" servers on one shared, physical server. On a vServer, you enjoy the privilege of unrestricted (root) access at a fraction of the cost of a dedicated server. These virtual servers share the actual hardware resources with each other. The concept is often referred to as "VPS (Virtual Private Server) architecture".

On the downside, VPS performance often suffers because of a bad default configuration, leading the whole idea ad-absurdum.
This page deals with fixing performance issues by changing the system configuration underneath Virtuozzo, as you will often find yourself limited by Virtuozzo hard limits set by your web host. I assume a standard "Virtuozzo plus Plesk" standard configuration in this tutorial. The screenshots stem from a "Virtual-Server L" VPS plan hosted at 1und1.de, the german division of 1&1.

Follow-up:
In the meantime, 1und1 fixed the "privvmpages" alarming issues by raising the memory limit to 100,000.

From a performance point of view, there are five VPS resources which tend to become problematic:
- memory (RAM) (mainly "privvmpages", "shmpages" and "vmguarpages" parameters),
- CPU ("cpuunits", "cpulimit" in Virtuozzo),
- Processes ("numproc"),
- Sockets ("numtcpsock" and "numothersock" parameters) as well as
- Disk usage ("diskspace").

Analysis

To get a first idea what might be causing performance issues, you can log into the Virtuozzo panel and check your vServer "Resources" tab. I suggest checking the Quality of Service alerts first of all as they provide a good, first hint.

As a general rule of thumb: Black alerts are "deadly" and should be your first action point. Yellow alerts can occur under heavy load. If they tend to show up regularly, look into it.
In this case, we can see a huge amount of privvmpages alerts which means there is a memory issue. This is a very common problem on a VPS since most companies have very strict limits on memory usage.
Once you have identified a first issue, a further look at the server resources is required to evaluate the degree of the problem.


Action

Memory
If RAM is a problem, you can stop all unnecessary System Services and disable their Autostart in your control panel.
You can configure server without a GUI? Deactivate Plesk.
You don't need any fileserver abilities? Disable smb.
No database required? Disable Mysql/PostgreSQL.
And so on.
You can also change the Apache tuning settings in /etc/apache2/server-tuning.conf and deactivate Keep-Alive using the "KeepAlive Off" option to save some memory at the cost of performance.
Sometimes, this is not enough. In my case, the virtual server was still struggling just running Joomla on Apache,PHP,MySQL.
On this specific 1und1 vServer, logging in as root and changing the available memory for MySQL by editing the /etc/my.cnf turned out to be successful. Furthermore, you can find additional memory intensive processes using the "ps -aux" command.

CPU
Key questions:
Do you run any CPU intensive scripts, eg. search engine scripts, which are called frequently (via Cron or by actual users)?
Can you implement a caching mechanism?
Is it possible to optimize the scripts?
Would it be a viable solution to outsource certain scripts or programs to another server?

Processes
On a Linux server, use the command "ps -aux" to view all system processes. On a Windows server, use the task manager.
A frequent reason for hitting the maximum allowed number of processes on a VPS is an Apache misconfiguration. Apache launches more child processes than the "numproc" parameter allows, thus a new process cannot be created anymore.
To fix this common issue, log into your server and edit your Apache config file (/etc/apache2/server-tuning.conf mostly) to allow less processes.

Sockets
Check for possible malware such as DDOS scripts.
Change the connection timeout and keep-alive parameters so old connections can be closed in-time to make room for new ones.
Do not use too many services at once.

Disk usage
Why are you running out of disk space? You shouldn't! Lack of space can bring your complete server to halt. Find the files in question, delete them and make sure they never come back.
If log files are filling up the server, implement a faster log rotation using file compression. I would not suggest disabling logging to ensure that debugging is still possible.

Restart the relevant processes and you'll have a server which is "all green", even under load.