Load Average in Linux: What It Means and How to Read It

What is load average, and what does it tell you about your server?

Load average is the average number of Linux processes that are running on a CPU, waiting for a CPU, or waiting in uninterruptible sleep for disk I/O, measured over 1, 5 and 15 minutes. Linux does not scale it to your core count, so you always read it next to the number of CPUs.

People often call it "server load". However, the phrase suggests a single percentage, and load average is not a percentage at all. Instead, it is a queue measure. In other words, it answers "how many tasks want resources right now?" rather than "how full is the CPU?"

The uptime manual page states it plainly: load average is the average number of processes in a runnable or uninterruptible state. A runnable process either uses the CPU or waits for it. An uninterruptible process waits for some I/O access, for example a disk read.

We are a digital marketing and web team, not a hosting company. So this guide leans on Linux man pages, kernel documentation and cPanel documentation. You will learn how to read the three numbers, how to tell CPU, disk and memory pressure apart, and when the right move is to hand the problem to your hosting provider.

Is load average the same as CPU usage?

No. The two numbers measure different things. CPU usage tells you how much of a time window the processor spent busy. Load average tells you how many tasks were using the processor or waiting in line for it. So a CPU can sit at 100 percent while load average reveals how long the line behind it has grown.

For example, consider a simple case. A single core server runs at 100 percent with one task in the queue. Its load average stays near 1. Now add four more tasks. CPU usage still reads 100 percent, yet load average climbs toward 5. In the second case every request waits longer for its turn.

Linux adds one more twist. Its load average also counts tasks that wait on disk. As a result, load average can climb while CPU usage stays low. When you see that pattern, the bottleneck usually lives in storage, not in the processor.

• CPU usage: How busy the processor is.
• Load average: How long the queue of tasks waiting for resources is, on average.
• %wa (iowait): The share of time the CPU sat idle while a disk request was still outstanding.

In short, you need all three together. None of them tells the full story alone.

Which commands show load average on Linux?

You do not need extra packages to check these numbers. The standard tools that ship with most Linux distributions already show them. Your quickest option is uptime.

uptimewcat /proc/loadavgtop

Here is a sample line with illustrative values: 10:15:02 up 12 days, 3:04, 2 users, load average: 0.52, 0.61, 0.70. The last three numbers cover the past 1, 5 and 15 minutes. The w command prints the same line along with logged in users. Meanwhile, top shows the same three values on its first line and refreshes them live.

The /proc/loadavg man page explains the file format. Its first three fields give the average number of jobs in the run queue (state R) or waiting for disk I/O (state D) over 1, 5 and 15 minutes. The fourth field holds two numbers in a "runnable/total" format. The fifth field shows the PID of the most recently created process.

For scripts, this file is the cleanest source. Instead of parsing uptime output, read /proc/loadavg directly, because its format does not change with language or locale settings.

What do the 1, 5 and 15 minute values mean?

The three numbers describe the same measure over different time windows. However, the real insight comes from how they relate to each other. These are not simple arithmetic means; older samples gradually lose weight. Therefore the 1 minute value reacts fast, while the 15 minute value moves slowly.

• 1 minute high, 15 minute low: Load just started rising. Think of a traffic spike, a cron job or a backup.
• 1 minute low, 15 minute high: Load is falling. The problem probably passed, but you should still find the cause in your logs.
• All three high and close together: Load is sustained. The server has worked above its capacity for a while.
• All three low: The queue is short. If the site feels slow, look at another layer.

For example, you might spot a high 1 minute value one morning and panic. However, if the 5 and 15 minute values look calm, you probably saw a brief spike. On the other hand, a 15 minute value that stays high for days points to a capacity or software problem rather than a passing wave.

That way you read the three values as a trend: is load rising, falling or stuck?

Why does your CPU core count matter?

Linux does not normalize load average for the number of CPUs. The uptime man page gives a clear example. A load average of 1 means a single CPU system stays busy all the time. On a 4 CPU system, the same value means the machine sat idle 75 percent of the time.

So the same number describes very different situations on different servers. Your first step is to find out how many logical processors your machine has.

nproclscpu

nproc prints the number of processing units available to the current process as a single number. lscpu lists cores, threads and sockets in more detail. On servers with hyper-threading, the logical processor count can exceed the physical core count.

On a VPS, keep one more detail in mind. Your virtual CPUs may not map one to one onto physical cores. Other tenants on the same host also share processor time. As a result, the same load average on a VPS can reflect different pressure than it would on bare metal hardware.

What is a good load average, and is the 1.0 per core rule right?

The common rule says the CPU queue starts to fill once load average approaches your core count. Roughly 1.0 per core works as a rough saturation threshold. That said, treat it as a starting point and a rule of thumb, not a hard limit.

The logic comes straight from the man page example. On a 4 core server, a load average of 4 means each core has one task on average and nothing waits. A load average of 6 means about two tasks wait in line on average. So once the value moves past your core count, requests start to queue.

Still, do not apply the rule blindly, because Linux also counts tasks that wait on disk. Ten processes stuck on slow storage can push the value up while the CPU sits almost idle. In that case, adding cores will not fix anything.

Here is the approach we recommend:

1. First, note your server's normal load average range on ordinary days.
2. Compare the value with your core count, but never use it as the only signal.
3. When it rises, confirm whether CPU, disk or memory drives it with separate tools.
4. Finally, decide based on whether users actually feel the slowdown.

Put simply, knowing your own baseline beats any fixed threshold you find online.

Worked example: how do you read load average on a 4 core server?

The table below works as an example calculation for a server with 4 logical processors. Also, the values are illustrative, not real measurements, and they only show the reasoning. Your own normal range may look different.

The last row matters most. When load average runs high while the CPU looks idle, spend your attention on storage instead of buying more processor power. Meanwhile, short spikes like the third row often trace back to a scheduled job or a sudden wave of visitors.

What causes a high load average?

A high load average is a symptom, not a cause. The same number can come from very different problems. On servers that host websites, these causes come up most often:

• CPU heavy work: Uncached dynamic pages, heavy PHP scripts, image processing, compression and search indexing.
• Disk I/O waits: Slow or full disks, large backup jobs, heavy log writing and database queries without indexes.
• Low memory and swap: Once RAM runs out, the kernel moves memory pages to disk, which adds disk waits.
• PHP-FPM and MySQL pileups: Many concurrent requests, long running queries and locked tables stretch the queue.
• Bot and attack traffic: Brute force login attempts or aggressive crawlers create load without real visitors.
• Virtualization waits: On a VPS, other virtual machines on the same host can take processor time.

For instance, if load rises on an online store during a sale, real traffic probably drives it. However, if load climbs at midnight when visits are lowest, a scheduled backup or bot traffic becomes the stronger suspect. To spot bot driven load, start by reviewing your access logs with our log file analyzer.

The next sections show how to separate these causes one by one.

How do you tell if CPU work drives the load?

First, open top and look at the %Cpu(s) line near the top. It shows fields such as us (user space), sy (kernel), id (idle), wa (I/O wait) and st (time stolen from the virtual machine).

With CPU bound load, us or sy runs high and id runs low. Also, press 1 inside top to see each processor on its own line. If one core stays pinned while the others idle, a single threaded process may form the bottleneck.

ps -eo pid,user,%cpu,%mem,comm --sort=-%cpu | head -n 15

In practice, this command lists the fifteen processes that use the most CPU. If php-fpm, mysqld or a backup tool sits at the top, you can narrow your search in that direction.

On a VPS, watch the st value too. The iostat man page defines steal as the share of time a virtual CPU spent in involuntary wait while the hypervisor served another virtual processor. If that number stays high, the problem lies in how the host shares hardware, not in your code. In that situation, talk to your hosting provider instead of tuning software.

How does disk I/O wait inflate load average?

On Linux, a process that waits for disk enters uninterruptible sleep, also known as state D. Load average counts these processes too. So when storage slows down, the value rises even while the CPU sits idle. This is the most common source of confusing numbers on web servers.

To diagnose it, check the wa value in top first. Then list processes in state D and pull extended statistics per disk:

ps -eo stat,pid,user,comm | awk '$1 ~ /^D/'iostat -x 2 5

iostat belongs to the sysstat package; if it is missing, install sysstat with your distribution's package manager. According to the iostat man page, %iowait shows the share of time the CPU sat idle while the system had an outstanding disk request. The await columns give the average time in milliseconds for requests to finish, including queue time. Meanwhile, %util shows how much of the elapsed time the device spent busy.

Read %util with care, though. The man page notes that a value near 100 percent signals saturation for devices that serve requests one at a time. Modern SSD and NVMe drives handle requests in parallel, so a high %util does not always mean saturation on them. That is why rising await values make a more reliable warning sign.

A lasting fix for a disk bottleneck often means a hardware or plan change rather than a software tweak.

How do low memory and swap raise server load?

When RAM runs short, the kernel moves rarely used memory pages to swap space on disk. In practice, swap acts as a safety margin that keeps the server alive during a sudden memory spike. However, disk is far slower than RAM. When the system keeps writing pages out and reading them back, processes wait on disk and server load climbs.

free -hswapon --showvmstat 2 5

free -h shows total, used and available memory in readable units. swapon --show lists active swap areas. According to the vmstat man page, si shows memory swapped in from disk per second, and so shows memory swapped out to disk per second.

That said, what matters here is swap traffic, not swap size. If swap usage looks high but si and so stay near zero, old idle pages simply sit on disk, which rarely hurts. On the other hand, if si and so stay above zero, the server is short on memory.

If memory runs out completely, the kernel's out of memory handler may kill a process. You can look for traces in the kernel log with journalctl -k | grep -i "out of memory". We cover sizing and creating swap step by step in our Linux swap file and SSH hardening guide.

How do PHP-FPM and MySQL push load average up?

On websites, PHP-FPM and MySQL are the two classic sources of load. PHP-FPM runs each dynamic request in a child process, and the pm.max_children setting caps how many children can run. If you set the cap too high, concurrent processes eat memory and push the server into swap. If you set it too low, requests queue up and the PHP-FPM log shows a server reached pm.max_children setting warning.

On the MySQL side, slow queries without indexes burn both CPU and disk. To see queries that run right now, use SHOW FULL PROCESSLIST; inside MySQL. For a lasting diagnosis, turn on the slow query log with the slow_query_log and long_query_time variables. Our MySQL install and performance tuning guide walks through these settings safely.

A missing cache also hurts both layers. Check your OPcache settings so PHP does not recompile scripts on every request. For repeated queries and session data, caching with Redis or Memcached can noticeably lower the load.

In short, PHP-FPM and MySQL problems rarely need a bigger server. They usually need less repeated work and better queries.

How do you read vmstat output for a diagnosis?

vmstat works as your fast triage tool because it sums up CPU, memory, swap and disk on one line. The command vmstat 2 5 prints five reports two seconds apart. The man page notes that without a delay, vmstat prints a single report with averages since boot. So skip the first line and read the ones after it.

Based on the definitions in the vmstat man page, focus on these fields:

• r: The number of runnable processes, running or waiting for run time. If it stays above your core count, a CPU queue has formed.
• b: The number of processes waiting for I/O to complete. If it stays above zero, look at the disk.
• si / so: Swap in and swap out. Constant nonzero values point to memory pressure.
• wa: Time spent waiting for I/O.
• st: Time stolen from a virtual machine.

This way you see which component feeds the load. For example, high r with low b means CPU bound load. Conversely, high b and wa put disk waits in front. If si and so also run high, low memory most likely causes those waits.

What should you check in top and htop?

top comes with nearly every Linux server. htop offers a more readable, colored interface, and most distributions ship it as a separate package. Both tools show the same core data; only the presentation differs.

When you open either one, we suggest this order:

1. Load line: The three values and their trend. Compare them with your core count.
2. CPU line: The us, sy, wa and st shares. This is where you first tell the load type apart.
3. Memory and swap lines: Available memory and swap usage.
4. Process list: The processes that use the most CPU or memory. In top, the P key sorts by CPU and the M key sorts by memory.
5. Process state column: A D in the S column means that process waits on disk.

That said, these tools only show a snapshot. If the problem hits at 3 a.m. and you look at 9 a.m., the screen shows nothing useful. You therefore need a monitoring system that keeps history. The data collection feature of the sysstat package or your host's monitoring dashboard fills that gap.

What is PSI, and what does it add to load average?

PSI (Pressure Stall Information) is a Linux kernel feature that measures resource pressure separately. Load average blends CPU and disk waits into one number. PSI instead offers separate files for CPU, memory and I/O under /proc/pressure/.

cat /proc/pressure/cpucat /proc/pressure/memorycat /proc/pressure/io

According to the Linux kernel PSI documentation, each file contains two lines, some and full. The some line shows the share of time in which at least some tasks stall on that resource. By contrast, the full line shows the share of time in which all non idle tasks stall at once. The avg10, avg60 and avg300 fields cover 10, 60 and 300 second windows.

In practice, the benefit is simple. When load runs high, PSI tells you directly which resource runs short. For example, if the io file shows high values while the cpu file stays low, the trouble lies in storage, not the processor.

However, these files may not exist on every system, since kernel version and configuration decide that. If they are missing, make the same split with vmstat and iostat.

Where can you see server load in cPanel and WHM?

If you have WHM access on your own server, you can check server load without a terminal. The cPanel documentation for Service Status says the System Information section lists the server's load, the current memory used, the current swap space used and the status for these items.

The same page explains the status icons. A checkmark means you use less than 80 percent of the resource. A warning triangle means between 80 and 89 percent. An X icon means 90 percent or more. These thresholds belong to cPanel's own display; they are not a general Linux rule.

Shared hosting works differently. As a cPanel user, the total server load does not reflect your own site, because other accounts run on the same machine. Some providers apply per account resource limits and offer a resource usage screen inside cPanel for your account. We explain how account isolation works in our article on CageFS and account isolation in shared hosting.

So on shared hosting, instead of trying to fix server load yourself, check whether your own account keeps hitting its limits.

When is a high load average a real problem?

A high load average is not always an emergency. A nightly backup can push the value up for a few minutes; if users do not notice, that is a normal workload. To separate real trouble from noise, look for these signs:

• The 15 minute value stays well above your core count for hours or days.
• Page response times grow, the admin panel slows down or timeouts start to appear.
• Visitors occasionally hit 502 or 503 errors.
• Swap traffic stays high, or the kernel log shows out of memory events.
• Load rises at hours that traffic cannot explain.

For example, under heavy load PHP-FPM reaches its process limit and the web server starts to turn new requests away. Visitors then see an error page. We cover how to diagnose that error in our guide to the 503 Service Unavailable error.

In other words, the test is not "is the number high?" but "does it hurt user experience and uptime?"

How does load average relate to a slow website?

When server load runs high, every request waits in line for the processor or the disk. That wait stretches the server's time to first byte. As a result, visitors wait longer before the page starts to appear. So high load ranks among the direct causes of a slow site.

The relationship works in one direction only, though. If your site feels slow while load stays low, the cause probably lives elsewhere. Large images, heavy JavaScript files, a slow third party API or DNS delays do not show up in this number. We list the full set of server side causes in our article on why a website is slow.

Slowness also affects more than visitors. A server that answers slowly makes both people and search engine crawlers wait, which can limit how efficiently bots fetch your pages.

Therefore, read two measurements side by side: load average on the server and real page load time on the user side. If one runs high and the other looks normal, you can quickly tell which layer holds the problem.

In what order should you fix high server load?

In a panic, rebooting the server looks tempting. However, a reboot does not remove the cause, and it also wipes the live data you need for a diagnosis. Instead, we recommend this sequence:

1. Capture the state: Save the output of uptime, top, vmstat 2 5 and free -h to a file.
2. Identify the type: CPU, disk or memory? The us, wa, si/so and b values point the way.
3. Find the process: Identify the process behind the load and its owner, such as a site, a user or a cron job.
4. Verify the traffic: Check access logs for sudden spikes, bots or brute force attempts.
5. Apply short term relief: Postpone a needless cron job, block hostile traffic and inspect any stuck query.
6. Move to a lasting fix: Caching, query tuning, PHP-FPM settings or more resources.

For instance, if brute force attempts on your login page create load, setting up Fail2ban blocks them at the server level. Leave hardware upgrades for last. Covering a software problem with a bigger server raises costs, and the problem tends to return.

When should you hand the problem to your hosting provider?

To be honest, you do not have to solve every high load issue yourself. In some cases, the right step is to open a ticket with your hosting provider's support team:

• You use shared hosting and the load runs high across the whole server; that sits outside your control.
• The st value on your VPS stays high; sharing the physical host is the provider's job.
• Disk latency looks hardware related, or the kernel log shows disk errors.
• You bought a managed service; changing server settings falls within that service.
• You have no root access, or you do not feel comfortable changing settings on the command line.

Also, attach evidence to your ticket. The time the problem started, uptime and vmstat output, the affected site address and your recent changes help support work much faster. That way your ticket turns from "my site is slow" into a measurable technical report.

If you keep running into capacity limits, also check whether your plan still fits your needs. We list the criteria for that decision in our guide on how to choose web hosting.

How do you build a habit of monitoring load average?

The best diagnosis starts before anything breaks: you need to know your server's normal state. So track load not only during a crisis but also in quiet periods. Once you know what a normal week looks like, you will notice an unusual morning right away.

A practical routine could look like this. Note your uptime and vmstat output once a week. Check again before and after campaigns or busy seasons. Look at the numbers after any large plugin or theme update. Also, set an alert threshold in your monitoring tool based on your core count.

Much of the load on a web server comes from the site itself: uncached pages, unnecessary plugins and unoptimized queries. Our team plans for these issues from day one in our web design and development projects, so the site serves more visitors with fewer resources on the same server.

To sum up, load average works like your server's pulse. It does not make a diagnosis on its own, but it helps you ask the right question: why did the queue grow, and which resource runs short?