Common VPS Issues and Solutions

Most VPS problems come down to a handful of causes: a process using all the CPU, memory running out, a full disk, a service that stopped, or a setting that is simply wrong. This guide gives the checks and fixes for each, for a Linux VPS you manage yourself. It applies to your own Domain India VPS, not to shared hosting, where the server settings are managed for you.

1. The five-command health check

uptime                        # load average; compare it with your vCPU count (nproc)
free -h                       # memory and swap
df -h && df -i                # disk space and inodes
systemctl --failed            # services that have stopped
sudo journalctl -p err -b     # errors logged since the last boot

Load well above your vCPU count means work is queuing; near-zero available memory with full swap means processes will soon be killed; a full disk stops databases, mail and logins.

2. High CPU usage

Find the cause. Run top (press P to sort by CPU) or htop. Note the process name and its user.

ps aux --sort=-%cpu | head -15

Fix it.

• A runaway process: stop it politely first with kill PID, and use kill -9 PID only if it ignores that. If it belongs to a service, restart the service instead: sudo systemctl restart name.
• Busy website: enable application caching and PHP OPcache, and look for slow database queries.
• Unknown process with a random name, or one using 100% of every core: treat it as a possible compromise, such as a cryptocurrency miner. Check crontab -l and /etc/cron.* for jobs you did not add. If an attacker has had root, a clean OS reinstall is the only state you can trust; see reinstalling your VPS OS.
• Genuine, steady demand: your workload has outgrown the plan.

3. Memory shortage and OOM kills

When memory runs out, the kernel's out-of-memory (OOM) killer stops a process, often your database.

sudo journalctl -k | grep -i "out of memory"   # what was killed, and when
ps aux --sort=-%mem | head -10                  # biggest users now

Add swap as a safety net on small plans, so a spike slows the server rather than killing services:

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

Then reduce what uses the memory:

• MariaDB or MySQL: lower innodb_buffer_pool_size and max_connections. The file is usually under /etc/mysql/ on Ubuntu and Debian, or /etc/my.cnf.d/ on AlmaLinux and Rocky Linux.
• PHP-FPM: in the pool file, lower pm.max_children or switch to pm = ondemand so idle workers exit.

4. Disk full

sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20   # what grew
sudo journalctl --vacuum-time=7d                                # trim the system journal
sudo apt clean && sudo apt autoremove --purge                   # Ubuntu/Debian
sudo dnf clean all && sudo dnf autoremove                       # AlmaLinux/Rocky
sudo lsof +L1                                                   # deleted files still held open

Old backups, logs and caches are the usual culprits. If lsof +L1 shows a large deleted file, restart the service holding it. If df -i shows 100% inodes, look for millions of small session or cache files.

Database binary logs can fill a disk quietly. If you don't use replication, you can purge old ones from the MariaDB or MySQL prompt: PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;.

5. 502 Bad Gateway and 504 Gateway Timeout

A 502 means the web server (usually nginx) could not get an answer from the application behind it, often PHP-FPM or a Node.js app. A 504 means the answer took too long.

sudo systemctl status php8.3-fpm             # use your PHP version
sudo tail -30 /var/log/nginx/error.log

• PHP-FPM stopped: restart it and read its log for the reason.
• Socket mismatch: the fastcgi_pass path in the nginx site must match the listen path in the PHP-FPM pool file.
• All workers busy: the PHP-FPM log says max_children was reached. Raise it only if you have the memory for it.
• Node.js app down: check it with pm2 status or systemctl status, and make sure it listens on the port nginx proxies to.

6. MariaDB or MySQL won't start

sudo systemctl status mariadb        # or mysql
sudo journalctl -u mariadb -n 50

The log usually names the cause. The common ones:

• Disk full: free space as in section 4, then start the service.
• Wrong ownership after a restore: sudo chown -R mysql:mysql /var/lib/mysql.
• InnoDB crash recovery: if the log reports corruption, copy /var/lib/mysql somewhere safe first. Then add innodb_force_recovery = 1 under [mysqld], start the server, export your databases with mysqldump, remove the setting and restore into a clean data directory. Raise the value only one step at a time, and only as far as needed to get a dump.

7. Email from a VPS not delivered

Sending mail directly from a new VPS is unreliable: its IP address has no sending reputation, and many receivers reject mail without a matching reverse DNS (PTR) record. Whether outbound port 25 is open and whether a PTR record can be set on your Domain India VPS are questions to confirm with support first.

The dependable route is an SMTP relay or transactional email service on port 587 or 465, with SPF, DKIM and DMARC records for your domain. See troubleshooting SMTP relay issues on a VPS.

8. Permissions, time and DNS

Permission denied. The web server runs as www-data on Ubuntu and Debian, and as nginx or apache on AlmaLinux and Rocky Linux. Give it ownership of the files it must write, and use 755 for folders and 644 for files:

sudo chown -R www-data:www-data /var/www/example
sudo find /var/www/example -type d -exec chmod 755 {} \;
sudo find /var/www/example -type f -exec chmod 644 {} \;

Never use chmod 777: it lets any process on the server change your files.

Wrong time. Set the time zone and turn on time sync: sudo timedatectl set-timezone Asia/Kolkata, then sudo timedatectl set-ntp true. Check with timedatectl. Cron jobs follow the system time zone.

Names don't resolve (for example apt update fails with "Temporary failure resolving"). Check with resolvectl status. On systems using systemd-resolved, /etc/resolv.conf is managed for you, so set DNS= in /etc/systemd/resolved.conf and run sudo systemctl restart systemd-resolved, or fix the resolvers in your network configuration (netplan on Ubuntu).

9. When to open a ticket

There is no VPS management page or power button in the Domain India client area. You reboot from inside with sudo reboot. Open a ticket when:

• the server needs starting after a power-off, or a force restart because it is frozen;
• you need an OS reinstall, console access or a resize;
• the VPS keeps crashing or rebooting on its own.

Include the VPS IP address, what happened and when, and the health-check output from section 1. Every ticket gets a first response within 15 minutes.

10. Domain India VPS

Domain India VPS plans are self-managed KVM servers with full root access and NVMe storage. You look after the operating system, software, security updates, monitoring and backups; support handles platform tasks such as starting, force-restarting or reinstalling the server on request. You can run the VPS without a panel or with CyberPanel, Webuzo or DirectAdmin; cPanel is not offered on a VPS.

If a server keeps running out of CPU or memory, a larger plan may be the fix. On 19 September 2026, Domain India list prices were ₹553 a month for VPS Starter (1 vCPU, 2 GB RAM) and ₹1,105 a month for VPS Basic (2 vCPU, 4 GB RAM), excluding 18% GST. To upgrade an existing VPS, open a ticket naming the server and the plan you want.

Ready to fix your server? Work through the checks above, keep the VPS monitoring guide handy, or compare VPS plans if you have outgrown yours. If the VPS needs a start, restart or reinstall from our side, open a ticket.