Troubleshooting common performance issues

A slow VPS is almost always short of one of four things: CPU, memory, disk or network. The fix depends on which one, so the job is to measure first and change second. This guide covers the checks and fixes for your own Linux VPS or server, where you have root access.

1. Start with a two-minute health check

Before changing anything, take a snapshot of the server:

uptime                 # load averages for 1, 5 and 15 minutes
htop                   # live CPU, memory and processes (press F6 to sort)
free -h                # memory and swap
df -h                  # free space on each filesystem
iostat -x 1 5          # disk activity (from the sysstat package)
sudo dmesg -T | tail -30          # recent kernel messages
sudo journalctl -p err -b         # errors since the last boot

Install anything missing with sudo apt install htop sysstat on Ubuntu or Debian, or sudo dnf install htop sysstat on AlmaLinux or Rocky Linux (htop comes from the EPEL repository there).

2. High load and CPU usage

The load average counts processes that are running or waiting. As a rough guide, a load that stays above the number of CPU cores (nproc tells you how many) means work is queuing.

• Find the culprit. In htop, sort by CPU%. ps aux --sort=-%cpu | head gives the same list as plain text.
• Look at the wa and st values in top. High wa (I/O wait) means the CPU is waiting for the disk, so the real problem is in section 4. High st (steal) means the host is not giving your VPS its CPU time; note the values and open a ticket with your provider.
• Fix the cause, not the symptom. A PHP site at 100% CPU is often a bot crawling uncached pages, a broken cron job or a plugin stuck in a loop. Check the web server access log for the busiest addresses and URLs.
• Stop a runaway process with kill PID, and use kill -9 PID only if it ignores the first signal. If a service keeps misbehaving, restart it with sudo systemctl restart name and read its log with journalctl -u name.

3. Running out of memory

Linux uses spare memory as disk cache, so "used" memory looks high on any healthy server. Look at the available column in free -h instead.

• Find the biggest processes: ps aux --sort=-%mem | head.
• Check whether the kernel killed something: sudo dmesg -T | grep -i -E "killed process|out of memory". A MySQL or PHP-FPM process killed here is a sure sign the server is over-committed.
• Right-size the big consumers. PHP-FPM's pm.max_children multiplied by the memory per PHP worker must fit in RAM alongside the database. On a server that mainly runs MySQL or MariaDB, innodb_buffer_pool_size is usually set to 50–70% of RAM; on a server that also runs PHP and a web server, use less.
• Add a small swap file as a safety net, so a brief spike slows the server down instead of killing the database:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Swap is not extra RAM. If the server swaps constantly, reduce what it runs or move to a plan with more memory.

4. Disk space and disk I/O

A full disk breaks databases, mail and logins, so check it first.

df -h                                   # which filesystem is full
df -i                                   # inodes: millions of small files can fill a disk too
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20

ncdu gives an interactive view if you install it. The usual space eaters are old logs, old backups kept on the same disk, cache folders and unused Docker images (docker system df, then docker system prune once you are sure). Limit the systemd journal with sudo journalctl --vacuum-size=500M, and see efficient log management in Linux for rotation.

For slow disk activity, iostat -x 1 shows how busy each disk is and sudo iotop -o shows which process is reading or writing. The most common cause is a database doing full table scans: find slow queries with the slow query log and add indexes, as explained in MySQL performance optimization.

5. Network bottlenecks and unwanted traffic

sudo iftop -i eth0        # bandwidth per connection (use your interface name from "ip a")
sudo nethogs              # bandwidth per process
ss -s                     # connection counts
ss -tn state established '( sport = :443 )' | wc -l

If a handful of IP addresses are making most of the requests, block them in your firewall, rate-limit logins and APIs at the web server (for example nginx limit_req), and consider a CDN such as Cloudflare in front of the site. Checking for DDoS attacks or excessive traffic from specific IPs walks through this in detail. For visitors who are far from the server, a CDN also cuts page load time.

6. Web server, PHP and database configuration

When the hardware is not the limit, the software settings usually are.

Change one setting at a time and measure again. For a fuller tuning and hardening checklist, see essential security and optimization tips for your VPS.

7. Malware and compromised accounts

An unexplained process using CPU, a server sending spam, or outbound traffic you can't account for can mean a compromise.

• Look for strangers: unknown processes in htop, unknown entries in crontab -l for each user, and unknown keys in ~/.ssh/authorized_keys.
• Scan with a tool such as ClamAV, and keep the OS, control panel and applications updated. Most break-ins come through outdated web applications and plugins.
• Lock down SSH with keys only and a firewall; see the SSH security hardening checklist.

If you confirm a compromise, rebuilding from a clean OS and restoring known-good data is safer than trying to clean the server in place.

8. Know when it is time for a bigger plan

If the server is tuned, caching is in place and it still runs out of CPU or memory at normal traffic, you have outgrown the plan. Keep a record of the numbers you measured; they tell you whether you need more memory, more CPU cores or faster storage. For continuous monitoring and alerts instead of one-off checks, set up Prometheus, Grafana and Loki.

9. Where Domain India fits

Domain India VPS plans are KVM virtual servers with full root access and NVMe storage. They are self-managed: you run the checks and changes in this guide yourself. The live VPS page says you can upgrade to a higher plan from the client area; if you don't see the option, open a ticket and support will help. If you would rather not manage a server at all, shared hosting keeps the server tuning on our side.

The cards show live Domain India prices, excluding 18% GST. VPS Basic's 4 GB of RAM leaves more headroom than Starter's 2 GB for a site with a database, PHP and a control panel on one server.

Ready to give your application more room? Compare plans on VPS hosting, read VPS vs shared hosting if you're unsure which you need, or open a support ticket with the numbers you measured.