9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] Understanding milli-CPUs (/dev/sysstat)
@ 2022-01-07 12:01 sirjofri
  2022-01-07 15:10 ` Benjamin Riefenstahl
  0 siblings, 1 reply; 4+ messages in thread
From: sirjofri @ 2022-01-07 12:01 UTC (permalink / raw)
  To: 9front

Hello all,

According to cons(3), load inside /dev/sysstat is a number in milli-CPUs. 
How is this number to interpret?

Looking at stats.c they compare the number with 1000 (times the number of 
cpus).

However, I have the following issue:

I wrote a daily script which sends me an email via a cron job. The mail 
contains this load value from /dev/sysstat.

When running the script like a normal shell script I get "reasonable" 
values (e.g. 147). Via cron in my mailbox I always read something close 
to 2000 (but always more than 1000).

Wouldn't it max out at 1000, since 1000 would be 100% cpu load? I don't 
understand the value properly, but that would make sense considering the 
details in stats.c.

And why is the value so different when running from a cron job? It's 
running on the same machine. However, rcpu to the same machine also makes 
a huge difference:

; cat /dev/sysstat
... 76 ...
; rcpu -h $sysname -c cat /dev/sysstat
... 512 ...

(The other numbers are very similar)

I don't understand it...

sirjofri

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] Understanding milli-CPUs (/dev/sysstat)
  2022-01-07 12:01 [9front] Understanding milli-CPUs (/dev/sysstat) sirjofri
@ 2022-01-07 15:10 ` Benjamin Riefenstahl
  2022-01-09  8:14   ` Anthony Martin
  0 siblings, 1 reply; 4+ messages in thread
From: Benjamin Riefenstahl @ 2022-01-07 15:10 UTC (permalink / raw)
  To: 9front

Hi sirjofri,

sirjofri writes:
> According to cons(3), load inside /dev/sysstat is a number in
> milli-CPUs. How is this number to interpret?
>
> Looking at stats.c they compare the number with 1000 (times the number
> of cpus).

My understanding is from Linux, but I hope this translates to Plan 9:
The load is the number of threads that are waiting in the scheduler for
time on some CPU, averaged over some time span.  So threads that wait on
some I/O in the kernel or on a synchronization primitive like
rendevous() do not count.  Only those threads are counted that will
actually use the CPU right away, once the scheduler lets them.

This means that 1 (thread) per CPU is fine, but everything above that
should better be temporary or intentional.  Otherwise you probably do
not have enough CPUs for your workload.  That's just a rule rule of
thumb, your mileage may vary as they say.

Counting the load in "millis" is probably just a way to avoid floating
point in the kernel.

> However, I have the following issue:
>
> I wrote a daily script which sends me an email via a cron job. The
> mail contains this load value from /dev/sysstat.

I see that this device is described in cons(3).  I do not see from that
documentation what time span sysstat uses.  It seems that you need to
write to the file to reset it and than read from it after some time.
But it also says that the vale is "decayed over time" which sounds like
some kind of moving average.  It does not say (unless I missed it), how
fast this decay is (i.e. again over which time span).

so long, benny

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] Understanding milli-CPUs (/dev/sysstat)
  2022-01-07 15:10 ` Benjamin Riefenstahl
@ 2022-01-09  8:14   ` Anthony Martin
  2022-01-09 12:36     ` Benjamin Riefenstahl
  0 siblings, 1 reply; 4+ messages in thread
From: Anthony Martin @ 2022-01-09  8:14 UTC (permalink / raw)
  To: 9front

Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> once said:
> > I wrote a daily script which sends me an email via a cron job. The
> > mail contains this load value from /dev/sysstat.
>
> I see that this device is described in cons(3).  I do not see from that
> documentation what time span sysstat uses.  It seems that you need to
> write to the file to reset it and than read from it after some time.
> But it also says that the vale is "decayed over time" which sounds like
> some kind of moving average.  It does not say (unless I missed it), how
> fast this decay is (i.e. again over which time span).

/sys/src/9/port/proc.c:/^accounttime

	/* only one processor gets to compute system load averages */
	if(m->machno != 0)
		return;

	/*
	 * calculate decaying load average.
	 * if we decay by (n-1)/n then it takes
	 * n clock ticks to go from load L to .36 L once
	 * things quiet down.  it takes about 5 n clock
	 * ticks to go to zero.  so using HZ means this is
	 * approximately the load over the last second,
	 * with a tail lasting about 5 seconds.
	 */
	n = nrun;
	nrun = 0;
	n = (nrdy+n)*1000*100;
	load = ((uvlong)load*(HZ-1)+n)/HZ;
	m->load = load/100;

Nrdy is the total number of procs in the scheduler queues.
Nrun is the number of procs running on each mach (cpu).

The multiplication and accompanying division by 100 is there
to handle precision problems with high values of HZ (the clock
tick frequency).

Cheers,
  Anthony

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [9front] Understanding milli-CPUs (/dev/sysstat)
  2022-01-09  8:14   ` Anthony Martin
@ 2022-01-09 12:36     ` Benjamin Riefenstahl
  0 siblings, 0 replies; 4+ messages in thread
From: Benjamin Riefenstahl @ 2022-01-09 12:36 UTC (permalink / raw)
  To: 9front

Anthony Martin writes:
> /sys/src/9/port/proc.c:/^accounttime
> [...]
> 	 * ticks to go to zero.  so using HZ means this is
> 	 * approximately the load over the last second,
> 	 * with a tail lasting about 5 seconds.

So we should interprete the load as approximately the average number of
waiting processes over the last second, but with a smoothed curve over
approximately 5 seconds.  Right?

>	load = ((uvlong)load*(HZ-1)+n)/HZ;

That's the formula for what we call the "moving average" these days, I
think.  HZ is the number of ticks per second, so the time span is one
second here.

so long, benny

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-09 12:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-07 12:01 [9front] Understanding milli-CPUs (/dev/sysstat) sirjofri
2022-01-07 15:10 ` Benjamin Riefenstahl
2022-01-09  8:14   ` Anthony Martin
2022-01-09 12:36     ` Benjamin Riefenstahl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).