Most shared hosting servers run CloudLinux. It’s the engine that keeps one noisy account from eating all the CPU. But configuring it is tricky. If you set the limits too tight, legitimate sites crash. If you set them too loose, one bad script takes down the whole box. I’ve seen both scenarios in support tickets. Usually, the admin just guessed the numbers. That’s how you end up with a server that feels unstable.
This guide covers the nine most common mistakes. We’ll look at the specific limit, why it breaks, and what to do instead. No fluff. Just the settings that matter.
1. Setting CPU Limits Too Low
This is the number one killer. Beginners often set the CPU limit to 10% or 20%. They think, "My site doesn't need much." Wrong. PHP processes spike. A single image resize can hit 100% CPU for a second. If your limit is 20%, the kernel throttles the process immediately. The site hangs. The user sees a timeout.
Check the current limit. Run this command:
lvecontrol --cpu <userid>
If you see a low number, raise it. For a standard shared account, 40-60% is a safe starting point. High-traffic sites might need 80-100%. Don’t fear 100%. LVE is fair. If everyone is at 100%, the scheduler balances them. If one is at 100% and others are at 0%, the heavy user gets all the time. That’s the point.
2. Ignoring the Entropy Limit
Entropy is often invisible until it’s gone. When entropy runs out, random number generation slows down. SSL handshakes stall. SSH connections hang. Users complain the site is "slow" but CPU and memory look fine. This is a classic hidden issue.
The default entropy limit is often too low for busy servers. Check it:
lvecontrol --entropy <userid>
If the value is low, increase it. A limit of 1000-2000 is usually safe. If you see users reporting intermittent SSL errors or slow logins, bump this up. It’s a cheap fix that solves a confusing problem.
3. Setting Inode Limits Too High
Inodes are file metadata. Beginners often set the inode limit to 100,000 or more. They think, "I have lots of files." But inodes eat memory. Each inode consumes a small amount of RAM. If you have 50 accounts, each with 100,000 inodes, you’re holding 5 million inodes in memory. That’s a lot.
Check the current inode usage:
lvecontrol --inodes <userid>
Look at the actual usage. Most shared sites use 5,000-15,000 inodes. Set the limit to 1.5x the current usage. If a site has 10,000 inodes, set the limit to 15,000. This gives headroom for growth without wasting RAM. If a site has 50,000 inodes, investigate. Why? Maybe it’s a WordPress site with tons of plugins. Or maybe it’s cached files that should be cleaned. Don’t just raise the limit. Fix the root cause.
4. Forgetting the I/O Limit
I/O limits control disk read/write speed. Beginners often ignore this. They set CPU and memory, but leave I/O at the default. The default is often low. If a site runs a database query that reads 100MB, it might get throttled. The query hangs. The site times out.
Check the I/O limit:
lvecontrol --io <userid>
The value is in bytes per second. A value of 100,000 is 100KB/s. That’s slow. For a standard site, 1-5MB/s is reasonable. Set it to 1,000,000 (1MB/s) as a baseline. If the site is database-heavy, go higher. I/O throttling is subtle. It doesn’t crash the site. It just makes it slow. Users blame the "server" when it’s actually the I/O limit.
5. Not Monitoring After Changes
You change a limit. You close the terminal. You never check if it worked. This is a huge mistake. LVE limits interact with each other. You raise CPU, but memory is still low. The site still crashes. You lower I/O, but entropy is low. SSL still hangs. You need to watch the metrics after a change.
Use lvecontrol --stats <userid> to see real-time usage. Watch it for 10-15 minutes during peak traffic. If CPU hits 100% constantly, your limit is too low. If memory hits the limit, you need more RAM or a code fix. If I/O spikes, check the disk. Monitoring is not optional. It’s the only way to know if your config is right.
6. Applying Limits to System Accounts
LVE is for user accounts. Not for system accounts. If you apply LVE limits to root, apache, or mysql, you break the server. Apache needs CPU to serve requests. MySQL needs memory to run queries. If you limit them, the server slows down or crashes. Beginners sometimes run lvecontrol on the wrong user. Check the user ID. Only limit accounts that have a home directory in /home/. System accounts should never be limited.
7. Ignoring the Context Switch Limit
Context switches are how the CPU switches between processes. If a site runs many small processes, it uses lots of context switches. The default limit is often low. If the limit is hit, the process is throttled. The site feels laggy. Check the context switch limit:
lvecontrol --context <userid>
If the value is low, raise it. A limit of 1000-2000 is a good start. If a site runs many concurrent requests, it might need more. Context switch limits are rarely the first thing you check, but they matter for busy sites.
8. Not Testing with Real Traffic
You set the limits. You test with curl or a single browser tab. It works. You close the test. You go home. Then the site gets real traffic. Ten users load the page at once. The site crashes. Why? Because one request is not ten requests. LVE limits are about concurrency. You need to test with multiple simultaneous requests. Use a tool like ab or wrk to simulate traffic. Run a test with 10-20 concurrent users. Watch the metrics. If the site slows down, your limits are too tight. Test under load. Not just in silence.
9. Assuming One Size Fits All
Every site is different. A static HTML site needs little CPU. A WordPress site with 50 plugins needs more. A PHP application with heavy database queries needs more I/O. Beginners often apply the same limits to every account. That’s wrong. Each account needs its own config. Look at the site’s actual usage. Check the logs. See what it’s doing. Then set the limits based on that data. Don’t guess. Measure. Configure. Test. Repeat.
How to Fix a Broken Limit
So what if you’ve already set a bad limit and the site is slow? Don’t panic. You can change it live. No reboot needed. Use lvecontrol to adjust the limit. For example, to raise the CPU limit to 60%:
lvecontrol --cpu 60 <userid>
Check the site. Is it faster? If yes, you fixed it. If no, check the other limits. Memory? I/O? Entropy? Work through them one by one. Keep a log of what you changed. If you make it worse, you can revert. LVE is forgiving. You can change limits on the fly. Use that to your advantage.
What to Check First
If you’re starting from scratch, here’s your checklist. First, check the current limits for each account. Note the values. Second, check the actual usage. Use lvecontrol --stats. Third, compare the limits to the usage. If the usage is close to the limit, raise the limit. Fourth, test under load. Fifth, monitor for 15 minutes. If the site is stable, you’re done. If not, adjust and repeat. This process takes time. But it’s the only way to get it right. Don’t skip the monitoring. Don’t guess the numbers. Measure. Configure. Test. That’s the practical starter approach. It’s not complicated. It’s just careful. And careful beats fast every time.
FAQ
Can I change LVE limits without restarting the server?
Yes. LVE limits are applied in real-time. Use lvecontrol to change them. No reboot needed. The changes take effect immediately.
What happens if I set the CPU limit to 100%? The user can use all available CPU if no one else is using it. If others are using CPU, the scheduler balances it. 100% is safe for most accounts. It doesn’t mean the user gets 100% of the server. It means they can use up to 100% of their fair share.
How do I find the user ID for an account?
Use id <username> or check /etc/passwd. The user ID is the numeric ID. Use that in lvecontrol commands. Don’t use the username. Use the numeric ID.
Should I limit all accounts? Yes. Every account should have limits. Even low-traffic ones. Limits prevent abuse. If one account goes rogue, it doesn’t take down the server. Set limits for everyone. Start with moderate values. Adjust based on usage.