Choosing the right limits is critical for stable, efficient shared hosting. Quite often there is a desire to set limits very low, so that any time customer's site hits those limits, the site would be throttled. The reality is that the cost of handing customer complaints, customer dissatisfaction, and the resulting churn, can outweigh the benefit of routinely adhering to strict limits. It’s important to strike good balance so that the limits are high enough that the majority of customers are unaffected, yet low enough to prevent system abuse without issue.
The CloudLinux OS comes with the ability to set CPU, Memory and concurrent connection limits. Those limits are critical for achieving stability in shared hosting environments.
CPU Limit controls the amount of CPU resources available for php/cgi scripts for the given account and is set by the smaller of two parameters: % of total CPU capacity (cpu) or number of CPU cores (ncpu) available to a given customer. The defaults are as follows:
ncpu=1
cpu=25%
Which means: customers are limited to the smaller of 1 core or 25% of total CPUs.
On 4, 8 or, 16 core servers it would mean that max usage per customer would be 1 core.
On a 2-core server it would mean ½ of a core per customer.
For single CPU servers this would mean ¼ of a core per customer.
This limit gives enough power for a customer's site to run fast, yet makes sure that if a customer starts to abuse the system, there are plenty of CPU resources left for others. CPU limit will prevent a single site from using more CPU resources then it was allocated. Interestingly enough, the majority of IO intensive applications are also CPU intensive, so CPU restriction alone can reduce IO issues as well.
VIRTUAL MEMORY Limit controls the total amount of virtual memory available for applications running within an account. By default, each customer is limited to 1GB of virtual memory. If a user application tries to use more than that such application will fail, as it hasn't been able to allocate memory. This usually shows up as error 500 (Internal Server Error) in a visitor’s browser.
The memory limit is the sum of virtual memory used by all applications in the account. It is important to note that we are limiting virtual, not physical memory. Multiple processes often share physical memory but don't share virtual memory. As a result you need to allocate much more virtual memory than physical memory. This is why it is important to leave virtual memory limits high enough.
ENTRY PROCESSES (Concurrent Connections) Limits the number of concurrent connections and cron jobs that an account can have at any one time.
Each time someone connects to Apache, a connection is used up. There are a limited number of slots in Apache web server for these connections (specified by MaxClients). It is set to 150 by default but often increased to 1000 or more on shared hosting servers. While connections are quickly served for static pages, dynamic pages take their time.
CPU throttling can cause such pages to take even longer to serve, tying up even more slots. Once all slots are used up, apache will not serve any new requests until existing requests are processed, bringing the whole server down. To prevent this issue we added another parameter that limits the number of concurrent connections a site can have. The default is 20. If a site has more than 20 concurrent connections to dynamic pages any further request will receive a 508 error (resource limit reached.)
It is important to note that concurrent connections are not the same as concurrent users. The majority of applications such as blogs, forums, etc., consider a user to be someone who visited a page within past 15-30 minutes. So, 300 concurrent users on the forum might mean only 5-6 concurrent Apache connections.
Adjusting Limits
By default, limits are optimized for servers with 50-5000 accounts and require no tuning. Yet, often there are just a couple of bad neighbors on a server that you might want to fence a bit more tightly. Sometimes you would want to adjust limits if some site is having an issue. The customer might be willing to pay more, or you feel that the customer deserves to be able to burst a bit higher, as he isn’t causing problems for the server. First, let’s figure out if the issue is related to limits imposed by CloudLinux:
If a site is slow, check if the site is hitting CPU limit. You can do that by running the lvetop utility, which will show real time results. Alternatively, you can check max CPU usage for the site via LVE Manager available via the WHM interface. If you see the site hitting CPU limit, the slowness of the site is caused by CloudLinux limits. Be careful adjusting CPU limit values. Adjusting them in small increments is recommended. You don't want to overload the whole server.
If the site is responding with a 508 error, the site is hitting concurrent connection limits. I always recommend checking lvetop/LVE Manager for CPU as well. If the user is hitting both concurrent connection limits and CPU limits, you might not want to adjust concurrent connections as it will not help and can cause server overload. In this case, increasing CPU might be a better solution as requests would get processed faster, and there will be a smaller number of concurrent connections for the site.
On the other hand, if a site is hitting concurrent connection limits, but not hitting CPU limit, you might want to increase max number of entry processes. As before, make sure you adjust the limit in small increments. The site might be hitting MySQL or IO hard, and the only thing stopping your server from being overloaded is the concurrent connections limit.
Memory limits are the trickiest. Visitors will get an error 500 (Internal Server Error) when the site hits the memory limit. This error might mean something is wrong with the script, with server settings, or it might be due to memory limits. Differentiating is easy; just go to LVE Manager and do a search “By Fault” and select memory. If you see that the site displayed in the search results it means that the memory limit was hit by that site. If you don't see it there the issue lies elsewhere.
