Performance monitoring on the vServer

intermediate · Last updated 16 July 2026

With a dedicated server, you want to know how it’s doing — CPU load, RAM usage, disk IO, network. Plesk has built-in monitoring, plus we run server monitoring in the background. Here’s what you can see yourself and when scaling makes sense.

What stats Plesk shows

In Plesk → Statistics:

Server resource overview

CPU load: current and history
RAM usage: used vs. available
Swap usage: hopefully near zero (if not: RAM is too small)
Disk usage: per volume, total
Disk IO: reads/writes per second
Network: inbound/outbound in Mbit/s

Values update by the second.

Per-end-customer statistics

If you host end customers:

Disk usage per end customer
Traffic per end customer
Mailbox sizes
DB sizes

Helps identify the biggest consumers.

Per-domain statistics

HTTP traffic (inbound/outbound)
Number of requests
AWStats / Webalizer for visitor analysis

Server performance tab

In Plesk → Tools & Settings → Server Performance:

Response time for standard Plesk actions
Active connections
Worker pool status (PHP-FPM)
Database connections

If something’s slow, you’ll find clues here.

Command-line tools (via SSH)

Via SSH (chrooted, per domain/subscription) you have the standard tools:

top              # process list with CPU load
htop             # the nicer variant
iostat -x 2      # live disk IO (installable via ticket)
vmstat 2         # system stats
free -h          # RAM usage
df -h            # disk usage

If htop or iostat isn’t installed: open a ticket, we’ll install it.

From the chrooted SSH you only see your own processes + public server stats. Deeper access goes through us.

Extended monitoring (add-on)

The default is Plesk’s own monitoring. If you want more:

Plesk monitoring extension

Email alerts on high load
Webhook notifications
Detailed metrics over time

Can be enabled in Plesk extensions.

Custom stack with Grafana / Prometheus

If you want your own monitoring dashboard (Grafana, Prometheus, Netdata), we set up the stack for you at OS level via ticket — including a reverse proxy on a subdomain of your choice. Tell us which metrics you want to see.

External monitoring service

UptimeRobot, Pingdom, BetterStack:

External pings to your domains
Alerts on outage
Performance metrics from the outside view

Recommendation: in addition to server-internal monitoring. The external view reveals problems that are invisible from the inside (DNS problems, ISP routing issues).

What we monitor in the background

Every one of our vServers runs:

Hardware health (temperature, disk S.M.A.R.T., RAID status)
VM health (CPU steal time, memory pressure)
Server OS logs (syslog, dmesg)
Plesk service status (web server, mail, DB, Plesk daemon)
Backup status

On critical events: we get an alert immediately. On hardware problems, we act before you even notice.

You don’t see these logs directly — if needed, we can look up specifics, just let us know.

When to scale

Indicators of a CPU bottleneck

CPU load persistently >80%
Plesk actions feel sluggish
Website TTFB (time to first byte) noticeably elevated

→ Plan upgrade to the next tier (more vCPU). We grow the VM live.

Indicators of a RAM bottleneck

RAM usage >90%
Swap active (should be rare)
OOM kills (out of memory) in the logs

→ Plan upgrade.

Indicators of a disk bottleneck

Disk usage >90%
Backups fail due to lack of space
DB performance drops

→ Plan upgrade or a data cleanup (delete old backups, clear caches).

Indicators of a disk IO bottleneck

Websites slow despite low CPU
DB queries take long
IO wait high in top

→ Storage optimization (DB indexes, query tuning). All plans already run on NVMe in RAID10 — if the IO bottleneck persists, open a ticket, we’ll look at the specific workload.

Indicators of a network bottleneck

1 Gbit connection persistently at the limit
High latency for end customers

→ Rare — usually not the bottleneck. If needed: multi-IP setup or custom bandwidth (ticket).

Scaling in practice

Plan upgrade, live

We can usually do this without downtime:

Increase vCPU
Increase RAM

Growing storage usually needs brief downtime (5-15 minutes).

Plan change: open a ticket, we do it. Effort on your side: none.

Scaling vertically vs. horizontally

Vertical (more resources per server): simple, always the first choice.

Horizontal (more servers): complex, for very large setups. Plesk doesn’t support this trivially — workarounds:

Multiple vServers, each with its own Plesk
A DB cluster (can be set up on request)
A CDN in front (Cloudflare, BunnyCDN)

For most setups, vertical is enough.

Bottleneck diagnosis

The classic workflow:

Where is the problem? — pin down the user report (“everything’s slow” isn’t enough)
When? — correlate with load peaks, cron jobs, external events
Which resource? — CPU, RAM, disk, network
Who’s causing it? — per domain, per container, per end customer

Plesk statistics cover steps 3 and 4. For steps 1-2 you need reports from end customers.

Performance tips for high load

WordPress caching

The WP Rocket or W3 Total Cache plugin
nginx FastCGI cache (can be set up via ticket)
Object cache with Redis

DB optimization

Check DB indexes (tools like Query Monitor in WordPress)
Identify long-running queries
Offload read-heavy workloads with a cache (Redis)

Static asset CDN

Put Cloudflare in front of your domains (free)
Serve static assets from the CDN
Cuts server load massively

PHP OPcache

On by default
For larger sites: increase realpath_cache_size
We tune the default values with our initial config

Frequently asked questions

Can I see CPU load per domain? Only to a degree. Plesk shows aggregates. Per-domain CPU tracking needs external tools (Grafana with per-vhost metrics, set up manually).

How early does Plesk warn me about a full disk? Default 80% and 95%. Adjustable in Plesk’s notification settings.

Seeing OOM kills — how? Needs the server log. Open a ticket, we’ll send you an excerpt.

How big can a domain get before performance suffers? Depends on the workload. WordPress with caching: 100 GB+ is no problem. Lots of small files (image gallery): gets sluggish from about 1 million files.

How many Plesk domains can a Studio vServer (8 vCPU, 16 GB) handle? Technically 50–80 is typical — that requires the Web Host Edition (unlimited domains). The included Web Admin Edition is limited to 10 domains, Web Pro to 30. With many high-traffic sites: fewer; the limit is often RAM (each PHP pool reserves a few MB), not CPU.

Does the Plesk backup block the server while it runs? The backup creates disk IO load. On small setups you won’t notice, on large ones you will. It runs at night by default. If needed, move it to a different time.

vCPU vs. real cores — what’s the difference? With us: vCPU = a dedicated physical core. No overbooking. If you have 8 vCPUs, 8 cores are reserved.

My server is suddenly slow — what to check first?

CPU load (top) — what’s running
Disk usage — full?
Mail queue (spam wave?)
WordPress login attempts (brute force?)
If unclear: open a ticket with the time window, we’ll check the logs