GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-08-08) - page 1 of 10
 
___________________________________________________________________
Linux Load Averages: Solving the Mystery
301 points by dmit
http://www.brendangregg.com/blog/2017-08-08/linux-load-averages....
___________________________________________________________________
 
fanf2 - 4 hours ago
I thought that including disk wait in the load average was a common
Unix feature. Sadly I can't go spelunking through the archives
right now, but it would be interesting to see what Solaris and BSD
do, for comparison with systems a little bit closer to Linux than
TENEX :-)
 
  swinglock - 4 hours ago
  It?s indeed different, Solaris doesn?t count time waiting for the
  disk in the load average.
 
  brendangregg - 4 hours ago
  Solaris and BSD load averages are based on CPU only. As for
  avoiding TENEX, here's the comment from the freebsd src:    /*
  * Compute a tenex style load average of a quantity on      * 1, 5
  and 15 minute intervals.      */     static void     loadav(void
  *arg)     {     [...]  :)
 
  [deleted]
 
sreque - 3 hours ago
One source of high load average spikes that I've seen in my job is
when a process crashes and generates a core dump. While the core
dump is being written, all threads in the process are in the
TASK_UNINTERRUPTIBLE state even though they are doing absolutely
nothing, and as such they all count towards the load average as if
they were spinning on on a CPU core. If the total virtual memory of
the process is large, say in the multi-GB range, coredumping can
take on the order of a minute, and Linux will report an
unreasonably high load average if that process had a lot of running
threads.Things like the above scenario make me treat the load
average metric with a lot of skepticism. I would much rather use
other metrics to infer load.
 
saalweachter - 2 hours ago
If it was bothering anyone else: yes, the parenthesis in the patch
in the email are unbalanced, and the code was checked in as:
if (*p && ((*p)->state == TASK_RUNNING ||
(*p)->state == TASK_UNINTERRUPTIBLE ||
(*p)->state == TASK_SWAPPING))
 
hathawsh - moments ago
This analysis cleared up a mystery for me. I've noticed that when a
server app is under heavy load in Linux, the load average goes high
if the bottleneck is the CPU or the disk, but the load average goes
low if the bottleneck is network resources (like databases or
microservice calls). I know why that happens, but it's very
unintuitive and it confused me when I was new to Linux. I thought
load average would measure the CPU load only. Now I know the
historical reasons for measuring system load instead of CPU load.I
kind of like it the way it is since it's handy to be able to
distinguish network load from CPU+disk load just by looking at the
load average. However, since the load average includes other stuff
as well, sometimes I still don't know what the load average really
means.
 
faragon - 5 hours ago
It incredibly detailed, including references and historical
investigation. Mind blowing. Kudos, Brendan Gregg.
 
js2 - 2 hours ago
It's been years but I really remember that Solaris load avg used to
similarly be affected by I/O, particularly NFS.
 
JaggerFoo - 4 hours ago
Great article. Interesting, insightful, and actionable.Cheers
 
ChuckMcM - 4 hours ago
Awesome analysis, I have added it to my favorites list. Around 1990
or so when I was in the kernel group at Sun and a team had just
embarked on the multi-processor kernel work that would later result
in the 'interrupts as threads'[1] paper. During that time there was
an epic thread on email which was something like "What the F*ck
does load average mean on an MP system?" (no doubt I have a copy on
an unreadable quarter inch tape somewhere :-(). If it helps, the
exact same pivot point was identified, which is this, does 'load
average' mean the load on the CPU or the load on the system. While
there were supporters in the 'system' camp the traditionalists
carried the day with "We can't change the definition on existing
customers, all of their shell scripts would break!" or something to
that effect. Basically, the response was if we were to change it,
we would have to call it something different to maintain a
commitment to the principle of least surprise. This has never been
an issue for Linux :-).As a "systems" guy I am always interested in
how balanced the system is, which is to say that I am always trying
to figure out what the slowest part of my system is and insuring
that it is within some small epsilon of the other parts. If you do
that, then system load is linear with workload almost regardless of
task composition. So disk heavy processes load the "system" as much
as "compute heavy" processes and "memory heavy" or "network heavy."
In an imaginary world you could decompose a system into 'resource
units' and then optimize it for a particular workload.[1]
http://dl.acm.org/citation.cfm?id=202217
 
  otoburb - 2 hours ago
  I wonder if Illumos / SmartOS and OpenIndiana continued with the
  principle of least surprise via their ancestry chain, or whether
  they also moved to a "system" load view like Linux.It's great
  that design decisions and thinking from decades past can be dug
  out and examined by complete strangers.
 
    rodgerd - 1 hours ago
    Of course, at this point, most people will be astonished when
    their Solaris (or Solaris-derived) or FreeBSD system shows CPU
    load instead of system load, given that most *ix exposure now
    happens via Linux.
 
    X86BSD - 2 hours ago
    Its called POLA in the FreeBSD world. Principle of least
    astonishment. So this exists outside solaris too. :)
 
      moosingin3space - 2 hours ago
      I've always seen POLA as "principle of least authority" in an
      OS research context, just fyi.
 
        X86BSD - 15 minutes ago
        I think the phrase has probably been mutated many times by
        various groups.
 
ge96 - 5 hours ago
Why isn't there one for ram in i3? I read something about how it's
hard to gauge ram usage despite htop displaying it as well as inxi
in general on Windows you look at task manager there is memory
usage.
 
  stephengillie - 1 hours ago
  Do you want RAM use, or virtual memory use?Here's an article on
  gathering this data on Windows with
  Powershell:https://www.petri.com/display-memory-usage-powershell
 
siebenmann - 4 hours ago
This is great work in general and excellent historical research.As
an additional historical note: in Unix, load averages were
introduced in 3BSD, and at that time they included processes in
disk IO wait and other theoretically short-term waits that weren't
interruptible. This definition was carried through the BSD series
and onward into Unixes derived from them, such as the initial
versions of SunOS and Ultrix. At some point (perhaps SunOS 3 to
SunOS 4, perhaps later), the SunOS/Solaris definition changed to be
purely runable processes.(I'm not sure what System V derived Unixes
such as Irix, HP-UX, and so on did, and their kernel source is not
readily available online for spelunking.)As of early 2016 when I
last looked at this, the situation on FreeBSD, OpenBSD, and NetBSD
was somewhat tangled. FreeBSD load average only included runable
processes, but NetBSD and OpenBSD counted some sleeping or waiting
processes as well.
 
  EvanAnderson - 1 hours ago
  When details of a piece of "open" software are so easily lost I
  shudder to think about the vast quantity of "closed" software
  that have had their history lost.I also kept thinking about how
  the term "software archaeology" (which I first saw in the 1999
  Vernor Vinge novel "A Deepness In the Sky") becomes more and more
  mainstream each day.
 
  brendangregg - 4 hours ago
  Thanks, I didn't know those Unix versions included disk I/O.
 
    cyphar - 14 minutes ago
    I think the reason for Sun changing it was due to the advent of
    NFS, which made measures of process based on I/O blocking
    inaccurate (and bound to network latency). I believe Cantrill
    mentioned this factoid at some point, but I don't recall the
    reference.
 
Filligree - 6 hours ago
Google cache:
http://webcache.googleusercontent.com/search?q=cache:taDucb9...
 
gciruelos - 3 hours ago
there's a very good (and old) article about linux load averages
here: http://www.linuxjournal.com/article/9001?page=0,0
 
ty_a - 5 hours ago
Holy crap, Brendan Gregg's site went down. Proof he is human I
guess?
 
  [deleted]
 
  brendangregg - 5 hours ago
  Yes, sorry. I guess proof this is a hobby on some personal
  hosting that can get overloaded. Try refreshing. Although it's
  load averages (couldn't resist) aren't that high:    10:36:09 up
  34 days, 20:05,  1 user,  load average: 2.39, 2.34, 2.08
 
    DamonHD - 5 hours ago
    Very good.And yes I'd noticed on many *nx systems that it
    didn't seem to be pure CPU (I think I once had a single-CPU
    SunOS 4.1.1 NFS server report into the tens or hundreds because
    disc was slow) I've mainly been treating it as if CPU for ~30Y.
    Goodness knows what I might have tuned better!Thank you!
 
    mmjaa - 3 hours ago
    Thank you for the superlative spelunking, that was a great trip
    down memory lane!  :)
 
    unilynx - 1 hours ago
    Load averages should probably get even higher and include
    network load - right now, a saturated ethernet card doesn't
    show up in the load(network card load is one of the next
    metrics I check next if load average and wait%/user% etc aren't
    telling what's wrong)
 
    ty_a - 3 hours ago
    Very much appreciate what you give away for free!
 
  rcarmo - 5 hours ago
  I still managed to read the whole thing. Quite fascinating,
  really, considering the lengths he went into tracking the ancient
  (1993) patch that turned CPU load averages into whole system load
  averages.
 
    dman - 4 hours ago
    I am beginning to suspect that Brendan Gregg is not a real
    person, but a collection of extremely talented individuals
    publishing under a pseudonym. (
    https://en.wikipedia.org/wiki/Nicolas_Bourbaki )PS: yes this is
    meant to be a compliment on the prolific output on performance
    related topics that Greg puts up on his page.
 
      brendangregg - 3 hours ago
      Thanks. It's clones.http://www.brendangregg.com/Images/brenda
      n_clones2006.jpg(I made that in response to a similar comment
      back then...)
 
        dman - 3 hours ago
        Thats amazing!
 
    pmoriarty - 4 hours ago
    I wonder what a what a good solution for aggregating all of
    this data and making it more easily searchable next time would
    look like, and if there's anyone working on it.It seems like
    such a waste to have it scattered all over the place, and for
    all the author's hard work in tracking it down to go to waste.
 
mnarayan01 - 5 hours ago
Page swapping seems like it makes a lot of sense to include in the
load average. Disk I/O seems like something more towards the
opposite end of the spectrum, though TASK_KILLABLE
(https://lwn.net/Articles/288056/) presumably mitigates this where
used.
 
mobilethrow - 3 hours ago
OT: what could cause a system to have a load of 1 when idle?I have
one (unimportant) Linux system that idles with a load of exactly 1.
The issue persists through reboots. It is a KVM virtual machine and
qemu confirms nothing is going on in the background.Any ideas how
to find out what's causing it?
 
  blinkingled - 3 hours ago
  Any processes stuck in D state?
 
    mobilethrow - 2 hours ago
    There is one, a [hwrng] process, but I don't think that's it.
    It's also in D state on other virtual machines on the same host
    without this symptom.(The process is probably from virtio-rng.)
 
      blinkingled - 1 hours ago
      I am assuming the guest (and host) kernels are sufficiently
      recent? I remember older kernels having a bug with load
      calculation. Does disabling Virtio-rng help? D state
      processes will cause rise in load average depending on
      NRCPUs.
 
  rkeene2 - 2 hours ago
  I have the same problem on my laptop after loading the nvidia
  kernel module -- so something in the kernel is always
  uninterruptible, but it's not a process that I can see in
  userspace.$ uptime; ps -L aux | awk '{ print $10 }' | sort -u
  15:57:37 up 21 days, 22:49, 16 users,  load average: 2.23, 1.61,
  1.61 R+ Rl S S+ S< SLs SN STAT Sl Ss Ss+ Ssl T $ ps -L aux|awk
  '($10 ~ /^R/){ print }' rkeene    1025  1025  0.0    1  0.0
  17980  2344 pts/10   R+   15:57   0:00 ps -L aux $
 
Florin_Andrei - 5 hours ago
> As a set of three, you can tell if load is increasing or
decreasingThat could be accomplished with a set of two.A set of
three could in theory give you acceleration.
 
  BayAreaSmayArea - 4 hours ago
  Never go to sea with two chronometers; take one or three.
 
    dullgiulio - 2 hours ago
    That's to measure error, not acceleration ;)
 
  btilly - 5 hours ago
  This comment makes perfect sense if load is a smooth function.
  But it is not.  It tends to be a step function.The most recent 2
  data points give you is whether the problem is currently getting
  worse, getting better or steady.  The third gives you a sense of
  whether it has been doing on a while.
 
    Florin_Andrei - 4 hours ago
    > This comment makes perfect sense if load is a smooth
    function. But it is not. It tends to be a step function.I think
    that depends on the sampling frequency, doesn't it? (given a
    modern OS with lots and lots of threads and processes)
 
      btilly - 4 hours ago
      No.  It depends on the fact that when something decides to go
      wrong, it frequently goes south fast.  So, for example, a
      busy lock in a database goes from 99% of capacity (using very
      little resources) to 101%, processes start backing up, and
      the system goes haywire.Think of it as being like traffic.
      Analytically it is easy to think of smoothly varying speeds.
      Reality is that there is a car accident, then a sudden
      traffic jam.  We are poking around to figure out where and
      when that traffic jam happened.  And sometimes the cars get
      cleared off the road and by the time we begin looking the jam
      is already evaporating.So comparing the 1 min and 5 min load
      averages tell us whether the jam is getting worse, holding
      steady, or improving on its own.  Looking at the 15 minute
      one tells us whether this happened recently.
 
        TylerE - 3 hours ago
        See aksiL swapPerformance tends to degrade rather...rapidly
        when you start to actually meaningfully swap actual working
        memory. With modern quantitys of RAM I'd almost prefer to
        just run swapless and let the system OOM so it can just be
        rebooted and get on with it...
 
      lkrubner - 3 hours ago
      No. Check out this video by Zach Tellman. He talks about
      queues and how they break down under load. One of the least
      intuitive things he points out is that when you have more
      processors, the breakdown tends to be more of a step
      function: everything is running smoothly till the moment that
      it isn't.https://www.youtube.com/watch?v=1bNOO3xxMc0The point
      he makes arises from basic queue theory and is applicable to
      all kinds of systems, and how those systems react to load.
      It's got little to due with particular hardware and
      everything to do with basic math.
 
    brendangregg - 5 hours ago
    FWIW, here's a quote from the Bobrow 1972 TENEX paper that I
    did not include (as the post was getting too long):"Three
    figures are better than just the last one, because from these
    the user can predict the trend as well as note local
    variation."
 
SoMisanthrope - 3 hours ago
Brilliant. Time to patch it back to CPU loads.