Your site takes three seconds to answer instead of 400 ms, the admin panel crawls when saving a single order, and no alert ever fired. A slow VPS is not automatically an undersized VPS: in most production cases we see, the cause shows up in three or four system counters before anyone considers a migration. The diagnostic below runs in seven steps, in the order you should execute them, with the commands to run and how to read each result. The goal: separate a saturated machine from a badly tuned application, and pay for an upgrade only when the measurements justify it.
A slow VPS is not always an undersized VPS
Three families of causes produce the same symptoms. Resources first: a processor shared with other guests on the host, too little memory, a full disk. Network next: latency, packet loss, slow DNS resolution. The application last: SQL queries without indexes, no cache, misconfigured extensions, overlapping scheduled jobs. Each one leaves a different signature in logs and counters, and none of them is fixed by adding a vCPU at random.
Before running a single command, characterize the slowness. Is it constant or does it come in spikes? Does it affect the whole site or a few pages? Do you feel it only from Morocco or from everywhere? That description already rules out half the leads.
- Constant slowness: load average high all day, often a memory leak or an unindexed database.
- Regular spikes: backup, import, cron job, email campaign, or traffic peak; the exact time of the spike usually names the culprit.
- A few pages only: one heavy query, a call to an external API, an uncompressed image.
- Quiet server, slow site: network, DNS, TLS, or the browser; the problem is not in the machine.
Steps 1 to 3: CPU, memory, and disk
Step 1 — Measure CPU steal
top shows a %Cpu(s) line whose st column (steal) is the time your machine wanted to run code but could not get the processor. Below 1–2%, steal is noise. Above 5% for several minutes, the contention comes from the host, not from your application. vmstat 1 10 confirms it second by second: a high sy column means too many system calls, a high wa column means disk wait, and an id column near 100 while users complain moves the problem somewhere else.
Step 2 — Memory, swap, and the OOM killer
free -m misleads people: the free column tells you nothing useful because Linux uses available memory for cache. Read available. If it stays below 10% of total RAM, the kernel starts swapping and response times blow up while the CPU looks calm. swapon --show and the si/so columns of vmstat 1 confirm constant swapping. Then check whether the kernel killed anything: dmesg -T | grep -i -E 'oom|killed process'. An OOM kill almost never leaves a log entry; PHP-FPM or MySQL vanishes and systemd restarts it. ps aux --sort=-rss | head names the process eating the memory.
Step 3 — Disk: space, inodes, and latency
df -h shows space, df -i shows inodes. A filesystem out of inodes refuses new writes while gigabytes remain free, a classic on servers that accumulate sessions and temporary files. Read latency with iostat -x 1 (package sysstat): on NVMe, %util near 100 and await above a few tens of milliseconds point to saturation. iotop -oPa identifies the process writing.
Steps 4 and 5: network and database
Step 4 — Network and resolution
Unlimited bandwidth does not rule out a bottleneck. ss -s counts sockets, ss -tulpn lists listening ports. Thousands of TIME_WAIT connections point to an app that opens a new connection per request instead of pooling them. mtr -rwzbc 100 your-domain.tld then locates packet loss and the hop where latency explodes. Do not skip DNS and TLS: a slow resolver adds hundreds of milliseconds to every outbound call.
Step 5 — Database
This is the most common cause of a slow site whose server looks idle. On MySQL or MariaDB, SHOW FULL PROCESSLIST; reveals running queries and their state, and the slow query log should be sorted by total time, never by average. On PostgreSQL, query pg_stat_activity: SELECT pid, state, wait_event_type, now() - query_start AS duree, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY duree DESC;. One unindexed query on a large table pins a full core for seconds. An undersized InnoDB buffer pool also causes permanent disk reads, visible in step 3.
Steps 6 and 7: application and cache
Step 6 — Application and scheduled jobs
Logs almost always hold the answer. journalctl -u php8.3-fpm --since '1 hour ago', the Nginx logs, and the framework logs show recurring errors, timeouts, and worker restarts. Check scheduled jobs: two overlapping crons (export, backup, sync) can pin a server for twenty minutes every hour without a clear trace in metrics. On Odoo as on WordPress, the installed module list is another lead: an unmaintained module can run a heavy query on every page load.
Step 7 — Cache and configuration
A site that recomputes every page on every visit saturates two vCPUs with no hardware fault at all. Check the HTTP cache, the object cache (Redis or Memcached), PHP OPcache, compression, and HTTP/2. A low OPcache hit rate means the cache is too small. On the web server side, the number of PHP-FPM workers must match the RAM actually available: too many workers on 2 GB reproduce the OOM from step 2.
When the diagnostic points to undersizing
If all seven steps come back clean — no abnormal steal, stable memory, reasonable %util, indexed database, active cache — and load still peaks during business hours, the plan is the limit. The table lists the five NVMe VPS configurations from Open Vista with prices, to choose between more RAM and more cores. Prices in US dollars per month, with the dirham equivalent excluding tax.
| Plan | vCPU | RAM | NVMe | USD/mo | DH excl. tax/mo |
|---|---|---|---|---|---|
| VPS-1G Démarrage | 1 | 1 GB | 30 GB | 9.99 | 94.48 |
| VPS-2G Business | 1 | 2 GB | 40 GB | 19.99 | 189.06 |
| VPS-3G Performance | 2 | 3 GB | 50 GB | 34.99 | 330.93 |
| VPS-4G Avancé | 2 | 4 GB | 80 GB | 39.99 | 378.22 |
| VPS-5G Ultra | 3 | 5 GB | 100 GB | 49.99 | 472.80 |
Every plan includes one dedicated IPv4, unlimited bandwidth, root access, a management panel (web console, reboot, reinstall, DNS), automatic backups, a firewall with DDoS protection, 24/7 monitoring, six-day-a-week support, and a 99.9% SLA on infrastructure. Delivery is announced in under fifteen minutes after ordering, and moving to a larger plan requires no painful migration.
One caveat for a Moroccan audience: production sits in New York, with latency of under 5 ms to New York, 8 ms to Ashburn, 10–20 ms to Montreal, and about 14 ms to Toronto. A Rabat datacenter is announced but not open yet, so do not design your architecture around it. For a site mostly visited from Morocco, network latency adds to application latency, and it is sometimes the network, more than the CPU, that explains the sluggishness people report.
FAQ
How do I know whether the problem is the VPS or my application?
Compare CPU load with traffic. Ten percent CPU and a slow site points to I/O, the database, the network, or the code; a load average above your vCPU count points to the machine.
Is high steal my responsibility?
No. Steal measures contention on the physical host, which you do not control. Record it with vmstat 1 10 over several minutes and send the numbers to support, who can move the instance or check the host load.
Should I reboot a slow VPS?
A reboot relieves the symptom but erases the evidence: the leaking process, the sockets, the memory. Capture free -m, top, dmesg -T, and iostat -x 1 first, then reboot if the service has to come back immediately.
Does a bigger plan always fix a slow site?
No. Without indexes and caching, a slow site stays slow with 5 GB of RAM. Upgrading fixes measured undersizing, not an unindexed query or a broken application module.
Run the seven steps in order, then decide
An hour of measurement and a handful of commands are usually enough to name the cause. If the verdict is missing resources, compare the NVMe VPS configurations from Open Vista on the VPS page, with current prices on the pricing page and direct ordering in the online store. If the verdict is application-side, the right decision is to fix the index, the cache, or the faulty module before spending another dirham.