33

The CPU doesn’t know any of this, the task scheduler does. The definition you quote is somewhat misleading; the current procfs(5) manpage has a more accurate definition, with caveats: iowait (since Linux 2.5.41) (5) Time waiting for I/O to complete. This value is not reliable, for the following reasons: The CPU will not wait for I/O to ...


20

Load is not equal to CPU usage. It is basically an indicator how many processes are waiting to be executed. Some helpful links: https://superuser.com/questions/23498/what-does-load-average-mean-in-unix-linux http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages


18

The CPU load is the length of the run queue, i.e. the length of the queue of processes waiting to be run. The uptime command may be used to see the average length of the run queue over the last minute, the last five minutes, and the last 15 minutes, just like what's usually displayed by top. A high load value means the run queue is long. A low value means ...


12

You're seeing the unexpected loadavg because of high iowait. 98.7 in the wa section of top shows this. From your screenshots I see the kworker process is also in uninterruptible sleep (state of D within top) which occurs when a process is waiting for disk I/O to complete. vmstat gives you visibility into the run queue. Execute vmstat 1 in typical sar ...


7

The load average is typically calculated by the kernel. Applications such as top and uptime may use the getloadavg(3) library call to access this (it's meant to be portable across different Unix versions). On Linux this typically results in a read from /proc/loadavg. On FreeBSD it's a system call. For example: #include <stdlib.h> #include <...


7

uptime shows system load (not exactly CPU usage), which is described in man uptime as follows: System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in uninterruptable state is waiting for some I/O ...


4

Linux, unlike most if not all other Unix like OSes, is not only counting processes using a CPU or waiting for a CPU in the run queue as a reference for its load calculation, but also add the number of processes (threads actually) being in uninterruptible state, i.e. waiting for for a disk or network I/O to complete. The latter are actually idle, i.e. not ...


4

The load average is computed in the kernel — see Why isn't a straightforward 1/5/15 minute moving average used in Linux load calculation? for details. So, you can't just get a reading with a finer resolution. Instead, you could write userspace code which duplicates the functionality, but that seems a little tricky (not least because to do it right, you'd ...


4

The load average is not something that is specific to any particular tool or distribution, it's a measurement provided by the Kernel, or more precisely, the scheduler, therefore it's a distribution independent measurement. The measurement is recorded inside the proc filesystem /proc Onto it's interpretation,the load average metric is not an indication of ...


4

A process in 'D' state is normally (but not always) "blocked on I/O wait". This can happen if a disk is busy and suffering high service times, for example. Process in D state count towards the load average, even though they're not using real CPU resources. In the case of NFS, a process can spend a lot of time in 'D' state waiting for the NFS server to ...


4

TL;DR, 23 is probably too high. The easiest way to think of load is "number of processes in the queue to use a CPU". If the load exactly matches the CPU count, the number of processes needing CPU exactly matches the available CPU, and you have ideal usage. If the load is higher than the number of CPUs available, then some processes had to wait for CPU to ...


3

Find another company. If they claim to rent you four cores, you should get four cores. A complaint that the load is 3.5 (which means you're using approximately three and a half cores, not four) and that it therefore is abusing their system, is ridiculous. There are many cloud providers who will happily allow you to run whatever you want...


3

Looking at the code for /proc/loadavg - yes, it's the same. The load average is read out from global variables. seq_printf(m, "%lu.%02lu %lu.%02lu %lu.%02lu %ld/%d %d\n", LOAD_INT(avnrun[0]), LOAD_FRAC(avnrun[0]), LOAD_INT(avnrun[1]), LOAD_FRAC(avnrun[1]), LOAD_INT(avnrun[2]), LOAD_FRAC(avnrun[2]), ...


3

Yes. You need to have set it up beforehand, but if you use the sar command with the sysstat package/facility, you can look back at the past month's daily data.


3

To solve your actual problem in one step: $ grep -o '201[1-4].[0-9]\+' file1.txt file2.txt file3.txt \ | datamash --sort -t: -g1 count 2 mean 2 file1.txt:8:2012.8125 file2.txt:6:2013.08 file3.txt:7:2013.6371428571 grep gets the values from the files, datamash counts the items and calculates averages by file. Now you have one line per file: filename:n:...


2

This really seems like the kind of question you should answer yourself: keep statistics while the machine is operating normally for a while (e.g. a week), and this will give you some idea of what the parameters of normal operation should be. Your snapshot shows you more or less maxing out one of two cores. Since your main process is multi-threaded, this ...


2

It's caused by the process exiting between top getting the process list and top trying to get info on that particular process. It's more common on a very busy box but generally safe to ignore. You might consider it a bug, you might not.


2

Another way to get the raw values would be to grep cpu0 /proc/stat. There you see the number of ticks in each state. Do man proc for the details on the interpretation. If you want it as a percentage you have to sum them together and divide, for example along the lines of what John W. Gill suggests.


2

There are several ways to accomplish sub-sccond polling of the cpu load, either by using a utility, like dstat, (example below) or by directly polling /proc/stat, (example also below). Let’s go over the pros and cons for both, before going on to the technical examples. To use dstat, you will need to run a fast crontab( */1 *  *   *   * ) and pipe the ...


2

Once a Linux machine reaches the file descriptor limit, the load won't raise, but the machine will be unable to write anything else on disk and will practically stop working. Similarly, reaching TCP connections limit means that the machine won't be able to accept new connections, but this won't have any impact on load.


2

The problem was https://developers.google.com/speed/pagespeed/module/ which have done cache clean every hour. Configuration it to store files on tmpfs fixed the problem.


2

When your CPU Credit Balance is empty, the host (supervisor) just don't give any processor time (except very small) to your ec2. This very small amount is enough to ssh, but not enough to run hungry monster called java. Therefore the instance WILL lag, just because it sleeps certain amount of time whilst real world including players do not. The only ...


2

You notice the large values of st? Those are "stolen" CPU cycles -- cycles you can't use, because you have completely almost -- or fully -- depleted your CPU credit balance. The usage is 10% is averaged over some time window, probably 5 minutes. If you watch the output from top, you should see that 100% minus stolen minus idle is approximately 10% over ...


2

This is a hard one. If the load average is higher than number of CPUs (for too long), then this is a sign that things are queuing up. However if they are less, this is not a sign of anything. There can be one process, using 100% of a CPU, that is not getting its work done. On the other hand, if you have many low priority batch processes, with no real time ...


2

Please refer to Wikipedia article on Unix-style system load values: https://en.wikipedia.org/wiki/Load_(computing) In short, if this is a Unix-style load average value, you'll need to divide this value by the number of usable processor cores in the system, and then multiply by 100 to get a percentage value. As is, the Unix-style load value describes the ...


1

In the tradition of UTSL, I've pasted in the code that runs the calculation. Here, nrun=sched_load() is the total "ready to run" processes this instant and avg is pointing to a structure with 3 fixed point numbers (1,5,15 minutes). cexp are magic numbers to decay the values for 1,5 and 15 minutes. For reference, this is in /usr/src/sys/kern/kern_synch.c .....


1

It turns out that some of the MIBs installed on RedHat provide all the information needed here. Since my goal is to provide these values under an OID via SNMP, I can make use of SNMP and process the information. The all-cpu average is computed as 100-idle: function allCpuLoad { # get system idle value from # snmpget -v2c -cmdaf localhost UCD-SNMP-...


1

mpstat -P ALL -u | tail -n +5 | awk '{print (100-$12)}' explanation: mpstat reports processor statistics -P ALL for all cores -u show the utilization (stats from /proc instead of live measurements) tail -n +5 start with line 5 awk '{print (100-$12)}' print the 12th value of every line subtracted from 100


Only top voted, non community-wiki answers of a minimum length are eligible