I got a panicked call at 2 AM from a client whose website was down. I SSH’d in, checked the logs, and found the issue immediately: disk space was full. 100% full. The application couldn’t write anything, so it just stopped working. He’d been running that server for two years without ever checking disk usage. That call cost him about 5 hours of downtime and me a lot of sleep.
That’s the thing about Linux dedicated servers—most issues aren’t mysterious or technical. They’re usually just things that weren’t monitored properly or basic maintenance that got skipped. I’m going to walk you through the most common problems I see and how to actually fix them before they become 2 AM emergencies.
Disk Space Running Out (The Most Common Issue)
Seriously, I cannot stress this enough. Disk space fills up silently. Your application stops working. Users can’t upload files. Databases can’t write. Everything breaks, and nobody notices until someone complains.
Why it happens: Log files grow indefinitely. Temporary files accumulate. Package managers cache old downloads. Backups get saved locally. Your database dumps pile up.
How to check:
df -h
This shows you disk usage. If any partition is above 85%, you’re in the danger zone. Above 95%, you’re basically already broken.
Quick fix:
Find what’s taking up space:
du -sh /*
This shows the biggest directories. Usually it’s /var/log, /tmp, or /home.
For log files specifically:
sudo journalctl --vacuum=30d
This keeps only 30 days of logs. Adjust the number based on your needs.
For old package cache:
sudo apt clean
sudo apt autoclean
Permanent fix:
Set up monitoring so you know when this is happening. I’ll cover that later, but basically don’t ignore disk space warnings.
Also, set up log rotation so logs don’t grow forever:
sudo nano /etc/logrotate.d/yourapp
Add something like:
/var/log/yourapp/*.log {
daily
rotate 7
compress
delaycompress
notifempty
}
This keeps only 7 days of logs and compresses old ones automatically.
Memory Leaks Crashing Your Application
This one’s sneaky because everything works fine for days, then suddenly your site starts getting slow, then crashes.
What’s happening: Your application is slowly using more and more memory without releasing it. Eventually it runs out of RAM and dies.
How to spot it:
free -h
Check this regularly. If “available” keeps shrinking over time, you’ve got a leak.
top
Look at the memory column. If a process keeps growing from 10% to 30% to 50% of memory over hours or days, that’s your leak.
How to fix it:
First, identify which application is leaking. Node.js? Python? Database? Your own code?
For Node.js: Most memory leaks are in your code. Common causes are:
- Not closing database connections
- Event listeners that never get removed
- Circular references that prevent garbage collection
Check your code for patterns like:
// BAD - listener never removed
server.on('request', (req, res) => {
someGlobal.push(req);
});
// GOOD - listener is cleaned up
server.on('request', (req, res) => {
processRequest(req, res);
// Clean up when done
});
For Python/Flask: Common issues are:
- Database connections not being closed
- Large objects kept in memory
- Caching without expiration
Use a tool called memory_profiler to find leaks:
pip install memory-profiler
python -m memory_profiler yourscript.py
For Databases: If it’s your database using all the memory, that’s actually configuration. PostgreSQL or MySQL might just need tuning. Look up memory settings for your specific database version.
Temporary fix: Restart your application regularly using a cron job until you fix the actual leak:
0 */6 * * * systemctl restart yourapp
This restarts every 6 hours. Not ideal, but keeps you online while you debug.
CPU Usage Maxing Out
Your site slows down, everything feels sluggish, but there’s no error message. Usually means your CPU is pinned at 100%.
Check it:
top
Look at the %CPU column. If one process is using 95%+, that’s your culprit.
Why it happens:
- Inefficient code (O(n²) algorithm, infinite loops)
- Not enough worker processes for concurrent requests
- Runaway script or task
- Database query doing a full table scan
How to fix it:
If it’s a web application:
ps aux | grep your_app
See how many worker processes you have. If you have one worker handling 100 concurrent requests, obviously it’ll max out. Scale it:
gunicorn -w 16 app:app
Use more workers. Match it to your core count.
If it’s a specific runaway task:
kill -9 <pid>
Kill it immediately. Figure out why it’s running that way.
If it’s a database query:
-- For PostgreSQL
SELECT * FROM pg_stat_statements ORDER BY mean_time DESC LIMIT 10;
Find slow queries and optimize them. Usually it’s a missing index.
Out of Memory (OOM) Killer
Your application just dies suddenly with no error message. Check:
dmesg | tail -20
Look for “Out of memory: Kill process”. That’s the Linux OOM killer terminating processes because you ran out of RAM.
Quick fix: Add swap space. Swap is slow, but it’s better than crashing:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
This adds 4GB of swap. Swap is on disk so it’s way slower than RAM, but keeps you from crashing immediately.
Real fix: Reduce memory usage or get more RAM. Seriously, this is a signal you need more hardware.
High Load but Low Resource Usage
Your site is slow, but CPU and memory look fine. What’s going on?
Usually it’s I/O wait. Your disk or network can’t keep up.
Check it:
iostat -x 1 5
If %util is above 90%, your disk can’t handle the load.
iotop
See which process is doing disk I/O.
Fixes:
- Enable caching (Redis, Memcached)
- Optimize database queries (add indexes)
- Move to SSD if using spinning disks
- Increase disk I/O limits if it’s a VPS
For network I/O:
nethogs
See which process is using bandwidth.
Maybe your application is downloading huge files or uploading massive amounts of data. Optimize that or increase bandwidth with your provider.
Application Won’t Start After Reboot
You restart your server, and your application doesn’t come back up. This is bad because you don’t realize until users complain.
Why: Services aren’t set up to start automatically.
Fix it:
Create a systemd service file:
sudo nano /etc/systemd/system/myapp.service
Add:
[Unit]
Description=My Application
After=network.target
[Service]
Type=simple
User=appuser
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node app.js
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
Then enable it:
sudo systemctl enable myapp.service
Now it starts automatically on reboot.
SSH Access Locked Down or Slow
You can’t SSH into your server, or SSH is incredibly slow.
For lockout:
Check if SSH service is running:
# From a different machine that can reach your server
sudo nmap -p 22 your_server_ip
If port 22 is closed, contact your hosting provider. Maybe there’s a firewall issue.
If you locked yourself out with firewall rules:
sudo ufw disable
Disable the firewall if you got too aggressive with it.
For slowness:
SSH might be trying to do DNS lookups. Check your sshd config:
sudo nano /etc/ssh/sshd_config
Look for:
UseDNS no
Make sure it’s set to no. DNS lookups during SSH can add 5-10 seconds of delay.
Unresponsive Server or Hanging Connections
Server seems fine but occasionally becomes unresponsive. Connections hang. Timeouts happen randomly.
Usually it’s network connectivity or packet loss.
Check:
ping 8.8.8.8 -c 100
Look at packet loss. If it’s above 1%, you’ve got a network problem. Contact your ISP or hosting provider.
Also check:
netstat -an | grep ESTABLISHED | wc -l
How many connections are open? If it’s tens of thousands, you’re running out of connection slots.
Increase the limit:
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
Security Issues Going Unnoticed
You don’t have monitoring, so you don’t know if you’re being attacked until it’s too late.
Basic monitoring setup:
Use a tool like htop or glances to watch what’s happening:
sudo apt install glances
glances
Use fail2ban to block brute force attempts:
sudo apt install fail2ban
Check logs regularly:
sudo tail -f /var/log/auth.log
Watch for failed SSH attempts.
Real monitoring:
Set up a monitoring service like Prometheus or use a hosted option. At minimum, get alerts when:
- Disk is above 80%
- CPU is above 80% for more than 5 minutes
- Memory is above 85%
- Service is down
Connectivity to Your Database
Your application can’t connect to the database even though the database is running.
Check:
mysql -h localhost -u appuser -p
or for PostgreSQL:
psql -h localhost -U appuser -d myapp_db
Can you connect manually? If yes, the database is fine. If no, database is the issue.
If the database service isn’t running:
sudo systemctl status mysql
sudo systemctl start mysql
If it won’t start, check logs:
sudo tail -f /var/log/mysql/error.log
If it’s a permissions issue:
-- In MySQL
GRANT ALL PRIVILEGES ON myapp_db.* TO 'appuser'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
Real Talk
Most Linux Dedicated Server problems aren’t complex. They’re just things that weren’t monitored. Set up monitoring, check your logs occasionally, and deal with issues before they become emergencies.
Get a hosting provider that actually supports you when things go wrong. Hostzop’s support has been solid for this kind of stuff. Their team actually helps debug issues instead of just saying “restart it.” When I’ve had clients on Hostzop servers run into problems, their support has jumped in and helped figure out what’s happening. They don’t just provide the hardware—they actually monitor things and alert you to problems before they become critical. They’ll help you set up monitoring and alerting properly so you’re not flying blind. That’s the kind of support that actually prevents the 2 AM emergency calls.
Checklist for Server Health
- Set up disk space monitoring
- Watch for memory leaks
- Monitor CPU usage
- Set up log rotation
- Ensure applications restart on reboot
- Check security logs occasionally
- Monitor network connectivity
- Test your backups actually work
Do these things and you’ll avoid 90% of the problems I see.