Hosting plans (both Shared hosting and Reseller hosting) are based on servers running CloudLinux. It’s a specialized OS Linux distribution oriented to shared hosting. It improves shared servers’ stability, density, and security by isolating each server user and allocating server resources. This helps to create an environment that is flexible and conveniently tailored to the needs of each user. To accomplish this, CloudLinux uses LVE (lightweight virtualized environment) technology. It provides each user with certain resources, which helps achieve a stable and optimally functioning server.
LVE technology provides each user with certain resources, which helps achieve a stable and optimally functioning server. All users are guaranteed the resources they have purchased. So, what resources are we talking about?
EP (Entry Processes)
Entry Processes control the number of entries into LVE. Each time the process enters the LVE, the value in the EP resource counter increases. When the process disappears from the LVE, the value in the same counter decreases. The processes created in LVE itself are not calculated. All this is also referred to as Apache concurrent connections.
When there is a new HTTP request for PHP/CGI, the process enter’s into LVE. Simply put, you can think of EP limit as of value, which determines how many PHP/CGI scripts can be executed simultaneously. Basically, each PHP page that the client visits will generate a single EP. However, you should not directly understand that 20 visitors can visit a website simultaneously if the EP limit is 20. The processes usually end so quickly that it is doubtful that 20 of them will happen simultaneously. However, this may be the case on a heavily visited website.
What happens if the EP limit is exceeded?
If the EP limit is exceeded, the webserver will serve error 508 page (Resource Limit Reached).
Recommendations to optimize EP
– Try optimizing your SQL queries
– Simplify the coding of your site
– If you are using WordPress, try to disable automated tasks (like wp_cron, admin-ajax.php)
– Block search engines using robots.txt
– Optimize the website by removing/disabling unnecessary plugins
NPROC (Number of Processes)
NPROC is somewhat similar to the limit described above (EP); however, instead of specific PHP/CGI requests, it includes all processes and threads within LVE. If the limit is reached, no new process can be created until one of the active ones dies. It is in such cases that NPROC resource counter increases. NPROC includes HTTPD, PHP and CGI processes, SMTP/IMAP, Sendmail, Cronjobs, etc. The NPROC usage number on LVE is usually low even under high activity, as non-PHP tasks are executed and completed quite quickly.
What happens if the NPROC limit is exceeded?
Apache might return 500 or 503 errors in such a case.
In general, both of these errors are quite abstract. However, if you notice such errors on sites hosted on our servers, it can be assumed that the NPROC limit has been exceeded.
CPU (SPEED limit)
CPU defines how much of the allocated CPU resources you are currently using. The allocated resources are the percentage of one CPU core. If CPU usage reaches 100%, that means the account uses all CPU resources allocated to it. In such cases, new processes will be put to sleep until existing processes are completed. This results in the website being slow and also time-out errors.
What happens if the CPU limit is exceeded?
When CPU allocation on your hosting plan is reached, it will stay at maximum and slow down other processes running on your server. Consequently, the entry process amount increases since the server cannot execute requests as quickly as possible when a CPU limit is exceeded. That would trigger 508 errors caused by EP. However, the CPU directly does not cause any error.
Recommendations to optimize CPU
– Use caching solutions. CPU firstly serves Cache before RAM. Because of this, tasks are served easier and faster than those that are processed via RAM.
– Use CDN solutions. Likely the most popular and free solution is Cloudflare.
– Try enabling Cloudflare railgun. It ensures that the connection between your server and the Cloudflare network is as fast as possible. Railgun will compress previously unreachable web objects. This can result in an additional performance increase.
RAM (Physical memory)
Tasks that need to be performed on the server needs temporary memory to store data. This memory is called RAM. It is affected by scripts and actions that visitors take on websites while accessing pages and MySQL queries. The data is removed once a task as such is completed. Other tasks can then use the memory.
In your hosting plans, you will see a physical memory limit. It is the actual memory allocated to your account. It corresponds to the amount of memory actually used by the end customer’s processes. If you exceed the physical memory limit, you may begin to experience PHP errors on your website. Usually, errors are brief, and once the usage has reduced, they will automatically clear.
What happens if the memory limit is exceeded?
As with exceeding the NPROC limit, the webserver returns 500 and 503 errors if the memory is exceeded.
Recommendations to optimize RAM
The recommendations we provided in the EP descriptions and CPU limits will help reduce memory usage accordingly.
Normally, a small site is recommended to have at least 512 MB of memory. So it would help if you kept in mind that while the smallest plan proposed can accommodate 10 domains, it provides 512 MB of memory. Placing multiple sites there may definitely not be enough of a resource. It is recommended to upgrade the package or host the sites in separate hosting plans in such cases.
IO and IOPS
IO stands for Input/Output. It is the speed with which the data transfer takes place between the hard disk drive and RAM. In other words, it measures active disk I/O time. It’s measured in MB per second. Likely, you would notice IO being used when disk-intensive tasks are performed on the server. An example of such a process can be generating a large backup on your account. Reaching the IO limit can cause all processes to slow down rapidly and take much longer to complete.
IOPS (Input/Output Operations Per Second) affects the number of read/write operations per second. If the limit is reached, read/write operations stop until the current second expires. Reaching this limit will cause a slow down on your account.
Both – IO and IOPS – are affected by other limits, such as RAM, CPU, EP, and NRPOC. If these resources are optimized, you should not face issues related directly to IO or IOPS limits.
Inodes (File Usage)
The Inode (index node) is a data structure in a Unix-style file system. It describes a file-system object such as a file or directory. The number of e-mails, website files, uploaded archives, images, or any other files on your hosting plan equals the number of Inodes.
Disk usage in our hosting plans is not only determined by how much GB of disk your data occupies an Inode. So it’s important to track Inode usage. Once the limit is exceeded, no more information can be uploaded to the server. Some features, such as cPanel, Webmail, email accounts, and so on, can be compromised if the Inode limit was reached. To find more information about Inode usage details, you can check this tutorial.
What to do when LVE limits are exceeded?
Troubleshoot the cause
1) The first to check if you see slow website performance or errors is the cPanel control panel. On the right side of the console, you can see your resource usage for the current period.
To see more and more accurate information, you should go to cPanel -> Resource manager. You can find a more detailed tutorial on checking resources with this tool here.
2) If you host more than one site on a server, you should determine which sites may have been the cause of the problem. The best way to do this is through cPanel -> Bandwith. It is usually the site that receives the most traffic and is the source of the problem.
3) Once you’ve identified the site that receives the most traffic, you need to check what queries have been made. This can be done through the Apache log. The cPanel Apache log can be found in two places:
– Recent records are stored in Raw Access
– Archives of previous entries can be found in File Manager -> /var/home/user/logs
Raw Access
Not in all cases, but often the problematic site can be judged by the size of the log file. If the log file is large, it indicates a large number of queries.
File Manager -> /var/home/user/logs
4) The Apache log file is read via a text editor on your computer (e.g., Notepad in Windows, TextEdit in macOS, vi/vim, or Pluma in Linux). After downloading the log file, open it with a text editor.
You will see in the log:
1) xx.xx.xxx.xxx – IP address of the client that made the request;
2) 01/Aug/2021:19:36:47 +0300 – date and time of the request;
3) GET /robots.txt HTTP/2.0 – request type and resource being requested;
5) 301/200/500, etc. – HTTP response status code;
6) Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://domain.com/robot/) – other information that in this case helps to identify that the robot executed the request.
4.1) First of all, try to find the value “bot” using the Find function (Ctrl/CMD + f). If you find many crawler queries, it is worth evaluating whether they are all useful for your site. Robot queries generate quite a lot of traffic to your site. Some queries from search engine crawlers like Google and Bing are useful. However, unseen robots may not benefit your site but generate traffic. In these cases, it’s a good idea to restrict them via robots.txt.
An example:
4.2) If you find many requests of type wp_cron and admin-ajax.php, you can try disabling these features. This saves some of the resources used by the server.
An example:
xx.xx.xxx.xxx - - [01/Aug/xxxx:21:59:30 +0300] "POST /wp-cron.php?doing_wp_cron=1627844370.2834479808807373046875 HTTP/1.1" 200 - "https://domain.com/wp-cron.php?doing_wp_cron=1627844370.2834479808807373046875" "WordPress/5.8; https://domain.com" xx.xx.xxx.xxx - - [01/Aug/xxxx:22:00:00 +0300] "POST /wp-admin/admin-ajax.php HTTP/2.0" 200 71 "https://domain.com/login/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0"
4.3) Also, try using a search to find HTTP requests with codes 508 and 503. Those requests will identify processes that the server failed due to exceeded LVE resources. You can try to optimize them in the ways outlined in the article above.
An example:
You can also find additional information about checking your Apache log in this tutorial.
It is important to keep in mind that website developers and programmers can best advise on website and resource optimization issues. Therefore, we always recommend discussing these types of problems with them in the first place.