From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7974 invoked from network); 7 Jan 2022 16:09:47 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2022 16:09:47 -0000 Received: from odoacer.turtle-trading.net ([93.241.193.16]) by 4ess; Fri Jan 7 10:53:00 -0500 2022 Received: from zenobia.turtle-trading.net ([192.168.2.111]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1n5qt1-0005Oz-5o; Fri, 07 Jan 2022 16:10:35 +0100 Received: from benny by zenobia.turtle-trading.net with local (Exim 4.94.2) (envelope-from ) id 1n5qt0-001DM4-Tu; Fri, 07 Jan 2022 16:10:34 +0100 From: Benjamin Riefenstahl To: 9front@9front.org References: <7e13be65-765d-4f6e-ad2a-e1646f01c53d@sirjofri.de> Date: Fri, 07 Jan 2022 16:10:34 +0100 In-Reply-To: <7e13be65-765d-4f6e-ad2a-e1646f01c53d@sirjofri.de> (sirjofri's message of "Fri, 7 Jan 2022 12:01:15 +0000 (UTC)") Message-ID: <87k0fbzimt.fsf@turtle-trading.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: persistence database property optimizer Subject: Re: [9front] Understanding milli-CPUs (/dev/sysstat) Reply-To: 9front@9front.org Precedence: bulk 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