What Causes High Server Load on Linux?

High server load is one of the most common symptoms administrators encounter when a Linux server begins performing poorly.

Websites become slow. Applications take longer to respond. SSH sessions may feel sluggish. Database queries begin taking longer. In severe cases, services may stop responding entirely.

The difficult part is that "high load" isn't a diagnosis.

It's a symptom.

At AcuNett, we've been administering and troubleshooting Linux servers for more than 25 years, and high server load can have many different causes. CPU exhaustion is one possibility, but disk I/O, memory pressure, database activity, PHP processes, backups, cron jobs, application problems, and malicious traffic can all contribute to an overloaded server.

Fixing high server load starts with understanding what the load actually represents and identifying which resource or process is responsible.

What Is Linux Server Load?

Linux load average provides a high-level indication of how much work the system is trying to process.

You can see the current load average with commands such as:

uptime

or:

top

You might see output similar to:

load average: 2.15, 1.84, 1.62

These three numbers represent the system's average load over approximately the previous:

• 1 minute
• 5 minutes
• 15 minutes

Looking at all three values helps determine whether load is increasing, decreasing, or remaining relatively consistent.

If the 1-minute value is substantially higher than the 15-minute value, load may have increased recently.

If the 1-minute value is much lower than the 15-minute value, the server may be recovering from an earlier period of heavy activity.

What Is Considered a High Load Average?

There isn't a single load average that is considered high on every Linux server.

The number needs to be interpreted in the context of the system.

A load average of 4 means something very different on a server with two CPU cores than it does on a server with 32 CPU cores.

As a very simplified starting point, a CPU-bound workload with a load around the number of available CPU cores may indicate that the processors are being fully utilized.

For example:

• A load of 2 on a 2-core server may represent significant utilization.
• A load of 2 on a 16-core server may be completely routine.

But even that comparison is incomplete.

Linux load isn't simply a CPU utilization percentage. Processes waiting on certain system resources, including disk I/O, can contribute to load.

That's why an administrator shouldn't look at a load average of 20 and immediately conclude that the server needs more CPU.

High Load Does Not Always Mean High CPU Usage

This distinction is extremely important when troubleshooting Linux performance.

A server can have a high load average while CPU utilization remains relatively low.

For example, numerous processes may be waiting for slow storage operations to complete. Those processes contribute to system load even though they aren't actively consuming large amounts of CPU.

Adding more CPU to that server may accomplish very little.

Before deciding how to correct high load, determine what the server is waiting on.

1. High CPU Usage

CPU saturation is one of the more straightforward causes of high server load.

A process or group of processes may simply require more processing power than the server has available.

Common causes include:

• Heavy website traffic
• PHP processing
• Complex database queries
• Image or video processing
• Application workers
• Compression jobs
• Backup processes
• Malware scans
• Runaway applications

The top command provides a quick way to see which processes are consuming CPU.

top

Another useful option is:

ps aux --sort=-%cpu | head

This can help identify processes currently using the most CPU.

The next step is determining whether that CPU usage is expected.

A database process using substantial CPU during a busy period may be legitimate. The same process consuming an entire server at 3:00 AM with no expected traffic deserves further investigation.

2. Disk I/O Bottlenecks

Disk I/O is one of the most important and frequently misunderstood causes of high Linux server load.

A server can have plenty of available CPU and memory but still perform poorly because processes are waiting for storage.

Heavy disk activity may come from:

• Databases
• Backups
• Large file transfers
• Log processing
• Email
• Malware scans
• Search indexing
• Temporary files
• Application caches

Storage performance is particularly important on servers running database-heavy applications or large shared hosting environments.

Tools such as iostat can help administrators examine storage performance:

iostat -xz 1

If processes are spending significant time waiting for storage operations, the underlying problem may be disk performance rather than CPU capacity.

3. Processes Stuck in I/O Wait

When investigating high load, administrators should look for processes waiting on I/O.

In process listings, a process in an uninterruptible sleep state is commonly represented by a D state.

You can inspect process states with a command such as:

ps -eo pid,ppid,user,stat,%cpu,%mem,cmd

A large number of processes stuck in a D state can indicate that something is preventing I/O operations from completing normally.

Possible causes include:

• Slow local storage
• Failing storage
• Overloaded storage arrays
• Network filesystem problems
• NFS connectivity issues
• Heavy backup activity

This can produce extremely high load averages even when CPU utilization doesn't appear excessive.

4. Memory Pressure

Insufficient memory can indirectly create serious performance problems.

Linux uses available RAM efficiently for applications and filesystem caching. Low "free" memory by itself isn't necessarily a problem.

What matters is whether the server has enough usable memory for its workload.

Memory can be reviewed with:

free -m

or:

free -h

If the server is under memory pressure, it may begin relying more heavily on swap.

That can dramatically reduce performance because accessing storage is much slower than accessing RAM.

5. Excessive Swap Usage

Swap is useful and normal in many Linux environments, but heavy swap activity can indicate that the server doesn't have enough memory for its current workload.

There's an important distinction between a server that has some data sitting in swap and one that is actively moving memory pages between RAM and swap.

Historical swap usage alone doesn't necessarily indicate a current performance problem.

Heavy ongoing swapping, however, can create substantial disk activity and slow the entire system.

Administrators need to determine why memory demand has increased.

Possible causes include:

• Too many PHP workers
• Database memory consumption
• Application memory leaks
• Traffic growth
• Too many simultaneous services
• Improper server configuration

6. MySQL or MariaDB Activity

On web hosting servers, the database is frequently involved in high-load incidents.

WordPress, Joomla, e-commerce platforms, and custom applications may execute large numbers of database queries.

Database-related load can result from:

• Slow queries
• Missing indexes
• Large tables
• Excessive concurrent connections
• Poor application queries
• Insufficient memory
• Improper database configuration
• High traffic
• Automated bots

Administrators can inspect active MySQL connections and queries to determine what the database is doing during a load event.

For example:

mysqladmin processlist

or from within MySQL:

SHOW FULL PROCESSLIST;

Slow query logging can also help identify queries that repeatedly consume excessive resources.

Simply restarting MySQL may temporarily reduce the symptoms, but it doesn't explain why the problem occurred.

7. PHP Processes

PHP is another common source of load on web servers.

A traffic spike can cause many PHP processes to run simultaneously. A poorly behaving WordPress plugin, Joomla extension, or custom PHP application can also consume significant CPU or memory.

PHP-FPM configuration is particularly important.

If worker limits are too low, requests may queue and websites become slow.

If worker limits are too high for the available server memory, too many simultaneous PHP processes can exhaust RAM and create a different performance problem.

PHP needs to be configured according to the workload and available server resources.

8. A Single Website Can Overload an Entire Server

On servers hosting multiple websites, one account can sometimes be responsible for a disproportionate amount of resource usage.

This can happen because of:

• A sudden traffic increase
• An inefficient plugin or extension
• A broken application
• A bot attack
• A compromised website
• A runaway cron job
• A large import or export

On a shared hosting server, it's important to identify resource consumption by account or website rather than assuming the entire server has simply outgrown its hardware.

9. Cron Jobs and Scheduled Tasks

Scheduled jobs are a frequent cause of mysterious load spikes that occur at predictable times.

A server may operate normally all day and suddenly experience high load every night at midnight.

The cause may be a cron job performing:

• Database maintenance
• Report generation
• Data synchronization
• File processing
• Search indexing
• Application maintenance
• Backups

When high load occurs at approximately the same time each day or week, scheduled tasks should be one of the first areas investigated.

10. Backup Jobs

Backups can be resource intensive.

A server may need to read large amounts of data, query or dump databases, compress files, and transfer backup archives to another storage location.

All of this can consume:

• CPU
• Memory
• Disk I/O
• Network bandwidth

Backup activity can become particularly noticeable on servers with large accounts, large databases, or many hosted websites.

Backups are essential, so the solution isn't simply to disable them.

Instead, administrators may need to adjust backup schedules, limit concurrency, improve storage performance, or change the backup architecture.

11. Overlapping Maintenance Jobs

Sometimes no single process is unreasonable by itself.

The problem is that several resource-intensive jobs run simultaneously.

For example, imagine a server starts all of the following at 2:00 AM:

• Full server backups
• Database maintenance
• Malware scanning
• Log processing
• Application cron jobs

Each job might run successfully on its own, but together they can saturate the server.

Scheduling resource-intensive tasks across different time periods can sometimes resolve recurring load problems without requiring additional hardware.

12. Malware and Compromised Websites

An unexpected increase in server load can sometimes be a security problem.

A compromised website or server may be used to:

• Send spam
• Attack other systems
• Run malicious PHP scripts
• Generate unwanted traffic
• Host malicious content
• Perform unauthorized background processing

Unexpected processes, unusual outbound connections, unexplained PHP activity, or sudden email volume should be investigated.

High load isn't proof of a compromise, but security should remain part of the troubleshooting process when resource consumption has no legitimate explanation.

13. Bots and Malicious Web Traffic

Not all website traffic comes from real customers.

Servers routinely receive requests from:

• Search engine crawlers
• SEO crawlers
• AI crawlers
• Vulnerability scanners
• Credential attacks
• Content scrapers
• Automated bots

A large volume of automated requests can generate substantial PHP and database activity, particularly when bots repeatedly request dynamic pages that aren't cached.

Web server access logs can help determine whether a sudden load increase corresponds with unusual traffic.

Depending on the cause, mitigation might involve firewall rules, rate limiting, application security controls, CDN or WAF services, or blocking abusive sources.

14. Traffic Spikes

Sometimes high load is simply the result of success.

A promotion, news story, email campaign, social media post, or other event may suddenly send far more visitors to a website than the server normally handles.

This is where historical monitoring becomes valuable.

If traffic has increased significantly along with CPU, PHP, and database activity, the server may legitimately need additional capacity or better caching.

Before upgrading hardware, however, administrators should determine whether the workload can be made more efficient.

15. Runaway Processes

A malfunctioning process can consume resources indefinitely.

Examples include:

• Application loops
• Stuck import processes
• Broken cron jobs
• Queue workers
• Custom scripts
• Compression processes

A process consuming unusually high CPU for an extended period should be investigated before simply terminating it.

Stopping the process may restore server performance, but understanding why it became stuck helps prevent the problem from recurring.

16. Email Processing

Mail servers can generate substantial load under the right conditions.

Possible causes include:

• Large outbound mail queues
• Compromised email accounts
• Spam campaigns
• Incoming spam volume
• Spam filtering
• Antivirus scanning
• Large mailboxes

On cPanel and other hosting servers that handle web, database, DNS, and email services together, a mail-related problem can affect website performance even though the websites themselves aren't responsible for the load.

17. Log Files and Logging Problems

Logging normally consumes relatively modest resources, but unusual application behavior can generate enormous amounts of log data.

A broken application may write the same error thousands of times per minute.

This can create:

• Additional disk I/O
• Rapid storage consumption
• Large files that become difficult to process

Review rapidly growing logs when disk activity or storage utilization increases unexpectedly.

18. Network Filesystems and Remote Storage

Not every disk operation occurs on a local drive.

Servers may depend on:

• NFS mounts
• Network storage
• Remote backup systems
• Shared filesystems

If a remote storage system becomes slow or unreachable, processes waiting for it may accumulate.

This can create a very high Linux load average while the local server's CPU appears relatively idle.

When processes are stuck in I/O wait, administrators should consider whether remote storage is involved.

19. Virtualization and Underlying Host Problems

A VPS can sometimes experience performance problems even when the guest operating system doesn't reveal an obvious cause.

The underlying physical server may be experiencing:

• Storage contention
• CPU contention
• Hardware problems
• Network issues
• Excessive workloads from other virtual machines

This is one reason infrastructure quality matters when selecting a VPS provider.

If the operating system doesn't show enough activity to explain poor performance, the virtualization layer and underlying infrastructure may need to be investigated.

20. The Server May Actually Need More Resources

Optimization doesn't eliminate legitimate capacity requirements.

A business may simply outgrow its existing server.

Traffic increases. Databases grow. Applications become more complex. More websites are added. Background processing increases.

If monitoring shows that legitimate workloads consistently consume the available CPU, memory, or storage performance, additional resources may be appropriate.

That might mean:

• Adding CPU
• Adding RAM
• Improving storage
• Upgrading a VPS
• Moving to a dedicated server
• Separating database and application workloads
• Distributing workloads across multiple servers

But capacity should be increased based on evidence rather than load average alone.

How Do You Troubleshoot High Linux Server Load?

There is no single command that diagnoses every high-load incident.

A useful investigation usually starts by examining several parts of the system.

Check the Load Average

uptime

Determine whether the load is currently rising, falling, or remaining high.

Check CPU and Running Processes

top

Look for processes consuming significant CPU or memory.

Check Memory

free -h

Review available memory and swap usage.

Check Disk Space

df -h

A filesystem approaching capacity can create application and service problems.

Check Inodes

df -i

Confirm that filesystems haven't exhausted their available inodes.

Check Disk I/O

iostat -xz 1

Look for storage devices experiencing heavy utilization or high latency.

Check Process States

ps -eo pid,ppid,user,stat,%cpu,%mem,cmd

Look for unusual numbers of processes waiting in uninterruptible sleep or other abnormal states.

Check Database Activity

Review active queries, connections, slow queries, and database resource consumption.

Check Web Traffic

Review access logs for traffic spikes, bots, crawlers, attacks, or one website generating disproportionate activity.

Check Scheduled Jobs

Determine whether backups, cron jobs, scans, or other scheduled processes correspond with the time the load increased.

Check System Logs

Review system, kernel, application, web server, database, and security logs for events occurring around the beginning of the incident.

Don't Start by Restarting the Server

When a production server becomes extremely slow, restarting it can be tempting.

Sometimes a reboot is necessary to restore service, but immediately rebooting can also destroy valuable evidence about what caused the problem.

Before restarting the server, when circumstances allow, capture information about:

• Load average
• Running processes
• CPU usage
• Memory
• Swap
• Disk I/O
• Process states
• Network connections
• Database activity

If the server is rebooted first and investigated later, the administrator may find a perfectly healthy system with no obvious explanation for what happened.

Don't Just Kill the Process and Call It Fixed

Terminating a resource-intensive process can immediately reduce server load.

But that only addresses the symptom if you don't understand why the process consumed those resources.

For example, if a PHP process became overloaded because a bot is repeatedly requesting an expensive application endpoint, killing the process doesn't stop the bot.

If MySQL is consuming CPU because an application is executing an inefficient query thousands of times, restarting MySQL doesn't correct the query.

Good troubleshooting asks why the process behaved that way.

Historical Monitoring Makes Troubleshooting Much Easier

One of the biggest challenges with high server load is that the administrator may not be watching the server when the problem occurs.

A customer reports that the website was slow at 10:15 AM, but by 10:30 everything appears normal.

Without historical data, there may be very little evidence left to investigate.

Monitoring can provide historical information about:

• CPU
• Load average
• Memory
• Swap
• Disk usage
• Disk I/O
• Network traffic
• Service availability

Correlating those metrics with web logs, database logs, cron schedules, and backup activity can make recurring performance problems much easier to identify.

Look for Patterns

The timing of high-load events can provide important clues.

For example:

• High load every night may point toward backups or maintenance jobs.
• High load during business hours may correspond with legitimate application traffic.
• High load every few minutes may indicate a cron job or queue process.
• High load following a software update may indicate an application or configuration change.
• A sudden unexplained increase may justify investigating traffic and security activity.

Patterns often reveal more than a single snapshot from the top command.

When Does High Load Require a Server Upgrade?

A server upgrade makes sense when monitoring and troubleshooting show that legitimate workloads consistently exceed the capacity of the current environment.

It doesn't make sense to upgrade solely because the load average occasionally spikes.

Short bursts of activity can be completely normal.

Before upgrading, determine:

• Which resource is constrained?
• Which process is consuming it?
• Is the workload legitimate?
• Can the application be optimized?
• Can caching reduce the workload?
• Can scheduled tasks be distributed differently?
• Would additional hardware actually solve the bottleneck?

If the server is CPU-bound, more CPU may help.

If it is memory-bound, additional RAM may help.

If it is waiting on slow storage, adding CPU and RAM may have little effect.

The upgrade should address the bottleneck that actually exists.

High Server Load Is a Symptom, Not a Diagnosis

This is the most important thing to remember when troubleshooting Linux server load.

A load average tells you that the system is busy or that processes are waiting.

It doesn't tell you why.

The cause might be legitimate traffic, an overloaded database, slow storage, insufficient memory, backups, cron jobs, bots, a compromised website, a network filesystem, or an application problem.

Experienced Linux administration is about connecting those symptoms to the underlying cause.

Linux Server Performance Troubleshooting from AcuNett

At AcuNett, we've been troubleshooting Linux servers for more than 25 years.

We work with Linux web servers, database servers, VPS environments, dedicated servers, control panels, and other business-critical infrastructure.

When a server is experiencing high load, our goal isn't simply to restart services until the numbers go down. We investigate what the system is doing, identify the resource bottleneck, determine which workload is responsible, and recommend a solution based on the underlying cause.

That may involve server optimization, database tuning, web server configuration, PHP configuration, storage troubleshooting, application investigation, traffic mitigation, or additional server resources.

A high load average tells you there's something worth investigating. Finding out why it's high is where Linux administration begins.