Guide CyberPanel on a Small VPS: Where the RAM Goes and How to Cut It (Tested)

Guide CyberPanel on a Small VPS: Where the RAM Goes and How to Cut It (Tested) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Getting Started Guides (https://adminsforum.com/Forum-cyberpanel-getting-started-guides)
+----- Thread: Guide CyberPanel on a Small VPS: Where the RAM Goes and How to Cut It (Tested) (/Thread-guide-cyberpanel-on-a-small-vps-where-the-ram-goes-and-how-to-cut-it-tested)

CyberPanel on a Small VPS: Where the RAM Goes and How to Cut It (Tested) - JAY - 10-28-2026

CyberPanel on a Small VPS: Where the RAM Goes and How to Cut It (Tested)

CyberPanel installs a lot more than a web server: OpenLiteSpeed, MariaDB, PowerDNS, a mail server, FTP, Docker, a memcached clone, fail2ban, a web terminal and the panel itself. On a 1 or 2 GB VPS that leaves little for your sites, and when RAM runs out the kernel kills the biggest process, usually MariaDB, and every site shows "Error establishing a database connection". We measured where the memory goes on our lab server (CyberPanel 3.0, OpenLiteSpeed 1.9.4, Ubuntu 24.04, 4 cores) and tested three things that help. Our server has 8 GB, but the numbers below are what each part uses, and those don't grow with the RAM you buy.

Step 1: See what uses the RAM

Code:

free -m
swapon --show
ps -eo rss,comm --sort=-rss | awk 'NR>1{a[$2]+=$1}END{for(k in a)printf "%7.0f MB  %s\n",a[k]/1024,k}' | sort -rn | head -16

The last line adds up the memory of all processes with the same name.
Our server at rest, RAM per program:
[Image: attachment.php?aid=644]

What we found, idle, with four small sites:

1.27 GB used before any visitor arrived.
Code:
lswsgi
(251 MB) is the CyberPanel panel itself.
Code:
litespeed
(164 MB) is the web server. Both stay.
Code:
mariadbd
(139 MB): already lean. CyberPanel ships MariaDB with a 128 MB InnoDB buffer pool and performance_schema off, so there's little to gain there.
Code:
lsmcd
(89 MB),
Code:
dockerd
+
Code:
containerd
(144 MB),
Code:
pdns_server
(62 MB) and
Code:
python
(65 MB, that's the web terminal on port 8888) run whether you use them or not.
Code:
lsphp
(87 MB) is PHP. At rest that's small; under load it's the biggest by far (Step 3).

The installer had already added a 2 GB swap file (

Code:

/cyberpanel.swap

) and set

Code:

vm.swappiness = 10

Code:

/etc/sysctl.conf

. Check that you have it too: swap won't make a small server fast, but it turns a crash into a slow moment.

Step 2: Stop the services you don't use

Docker (
Code:
docker
,
Code:
docker.socket
,
Code:
containerd
): only needed for the Docker Manager and Docker apps. We had no containers.
PowerDNS (
Code:
pdns
): only if your domains don't use this server as nameserver. With DNS at Cloudflare or your registrar, it answers nothing.
LSMCD (
Code:
lsmcd
): LiteSpeed's memcached, used by the LiteSpeed Cache object cache. If you stop it, switch off Object Cache in LiteSpeed Cache's settings so WordPress stops trying to connect.
Web terminal (
Code:
fastapi_ssh_server
): the browser SSH terminal in the panel. If you use normal SSH, you don't need it.

Code:

systemctl stop docker.socket docker containerd lsmcd pdns fastapi_ssh_server
free -m

Five services stopped, sites and panel still up:
[Image: attachment.php?aid=645]

That freed 145 MB (1244 to 1099 MB used), less than the per-program list suggests, because processes share some memory. On a 1 GB server that's 15% of the RAM. The site and the panel both still answered 200. To keep them off after a reboot:

Code:

systemctl disable docker.socket docker containerd lsmcd pdns fastapi_ssh_server

Don't stop

Code:

postfix

Code:

dovecot

and

Code:

opendkim

unless you're sure no site sends or receives mail through this server: password reset mails and contact forms often go through the local Postfix. Leave

Code:

fail2ban

and

Code:

firewalld

running. We started everything again on our server after the test.

Step 3: Limit PHP processes per site (the big one)
Every website on CyberPanel gets its own PHP pool, set in

Code:

/usr/local/lsws/conf/vhosts/DOMAIN/vhost.conf

(also in the panel: Websites > List Websites > Manage > vHost Conf):

Code:

extprocessor SITEUSER {
  ...
  maxConns                10
  env                     LSAPI_CHILDREN=10
  ...
  memSoftLimit            1024M
  memHardLimit            1024M
}

That's up to 10 PHP processes per site, each 40 to 50 MB with WordPress. Five busy sites can ask for over 2 GB of RAM just for PHP. We sent 20 visitors at once to our WordPress login page (not cached, so every request runs PHP and MariaDB) with

Code:

ab -n 800 -c 20

, and measured the PHP processes of that site. Then we set both values to 4 and ran it again:
The same load test, 10 PHP children vs 4:
[Image: attachment.php?aid=643]

Default: 14 PHP processes, 701 MB.
Limited to 4: 6 processes, 301 MB.
0 failed requests both times. Speed was about the same: across our runs we saw 25 to 42 requests per second with either setting, because our 4 CPU cores were the limit, not the number of PHP processes.

The rule of thumb: more PHP processes than CPU cores don't make PHP faster, they only use RAM. On a 1 to 2 GB VPS, 2 to 4 per site is plenty. Visitors above that wait briefly in a queue instead of pushing the server out of memory.

To change it (both lines, same number):

Code:

V=/usr/local/lsws/conf/vhosts/example.com/vhost.conf
sed -i -e 's/^\(\s*maxConns\s*\)10$/\14/' -e 's/LSAPI_CHILDREN=10/LSAPI_CHILDREN=4/' $V
grep -nE 'maxConns|CHILDREN' $V

The trap: restarting the web server doesn't apply it
After the change we restarted OpenLiteSpeed, ran the test again, and nothing had changed: still 14 to 19 processes. The reason: CyberPanel's PHP pools run detached from the web server, so

Code:

systemctl restart lsws

leaves the old PHP parent process running, with the old setting:
Restarting the web server didn't apply the change:
[Image: attachment.php?aid=642]

The PHP parent survived the restart (52 seconds old) and still had

Code:

LSAPI_CHILDREN=10

. Only after we killed that site's PHP processes did the next request start a new parent with

Code:

4

Code:

systemctl restart lsws
pkill -u SITEUSER lsphp

Find

Code:

SITEUSER

with

Code:

grep extUser /usr/local/lsws/conf/vhosts/example.com/vhost.conf

. Killing PHP is safe: the next visitor's request starts it again within a second. The same applies to every other PHP setting you change (

Code:

php.ini

values, extensions): if a change doesn't show up, kill the site's lsphp processes.

After changing the PHP version of a site in the panel, check vhost.conf again, in case the panel rewrote the block.

Also worth knowing

LiteSpeed Cache does most of the work. A cached page is served without PHP or MariaDB at all. The load test above deliberately used the uncached login page; on cached pages your RAM use barely moves.
bots and wp-login brute force are the usual reason a small server suddenly runs out of RAM: every attempt runs PHP. Limiting PHP processes (Step 3) is what keeps that from taking MariaDB down with it.
Find out if it already happened:
Code:
dmesg -T | grep -iE 'out of memory|killed process'
and
Code:
journalctl -u mariadb -n 50
.

Checklist for a 1 to 2 GB server

Swap file present and
Code:
vm.swappiness
low (CyberPanel's installer did both on ours).
Docker, PowerDNS, LSMCD and the web terminal stopped and disabled if you don't use them (145 MB in our test).
Every site:
Code:
maxConns
and
Code:
LSAPI_CHILDREN
at 2 to 4, then
Code:
pkill -u SITEUSER lsphp
.
LiteSpeed Cache on for WordPress sites.
Check
Code:
dmesg
for OOM kills once in a while.

More CyberPanel guides

Tested on CyberPanel 3.0 with OpenLiteSpeed 1.9.4, MariaDB 10.11 and lsphp 8.3 on Ubuntu 24.04 (4 cores, 8 GB RAM), October 2026, with ApacheBench against a WordPress 7.1 site. All settings and services were put back to their defaults afterwards.