Constant load of 1 on a recent 12-STABLE
Gordon Bergling
gbergling at googlemail.com
Thu Jun 4 13:44:07 UTC 2020
Hi Ian,
On Wed, Jun 03, 2020 at 02:40:07PM -0600, Ian Lepore wrote:
> On Wed, 2020-06-03 at 22:29 +0200, Gordon Bergling via freebsd-hackers wrote:
> > [...]
> >
> > The only key performance indicator that is relatively high IMHO, for a
> > non-busy system, are the context switches, that vmstat has reported.
> >
> > -------------------------------------------------------------------------------
> > procs memory page disks faults cpu
> > r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id
> > 0 0 0 514G 444M 7877 2 7 0 9595 171 0 0 0 4347 43322 17 2 81
> > 0 0 0 514G 444M 1 0 0 0 0 44 0 0 0 121 40876 0 0 100
> > 0 0 0 514G 444M 0 0 0 0 0 40 0 0 0 133 42520 0 0 100
> > 0 0 0 514G 444M 0 0 0 0 0 40 0 0 0 120 43830 0 0 100
> > 0 0 0 514G 444M 0 0 0 0 0 40 0 0 0 132 42917 0 0 100
> > --------------------------------------------------------------------------------
> >
> > Any other ideas what could generate that load?
>
> Interrupts/second consistently zero is the strange part of that vmstat
> output. That makes me think the problem has something to do with
> timekeeping and is a problem with the statistics used by top rather
> than having some "stuck process" actually consuming time.
>
> Are there any other signs of timekeeping trouble on the machine, like
> ntpd repeatedly stepping the clock? What's the output for
>
> sysctl kern.timecounter
> sysctl kern.eventtimer
first, sorry for the late response. The e-mail went into my spam folder.
There aren't any timekeeping problemes on that machine. The requested output
of the request sysctl trees are the following:
-------------------------------------------------------------------------------
$ sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) Hyper-V-TSC(3000) TSC-low(-100) Hyper-V(2000) dummy(-1000000)
kern.timecounter.hardware: Hyper-V-TSC
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 483840041
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.Hyper-V-TSC.quality: 3000
kern.timecounter.tc.Hyper-V-TSC.frequency: 10000000
kern.timecounter.tc.Hyper-V-TSC.counter: 1283654243
kern.timecounter.tc.Hyper-V-TSC.mask: 4294967295
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1600955785
kern.timecounter.tc.TSC-low.counter: 1215462580
kern.timecounter.tc.TSC-low.mask: 4294967295
kern.timecounter.tc.Hyper-V.quality: 2000
kern.timecounter.tc.Hyper-V.frequency: 10000000
kern.timecounter.tc.Hyper-V.counter: 1283862164
kern.timecounter.tc.Hyper-V.mask: 4294967295
-------------------------------------------------------------------------------
and
-------------------------------------------------------------------------------
$ sysctl kern.eventtimer
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 4
kern.eventtimer.choice: Hyper-V(1000) LAPIC(100) RTC(0)
kern.eventtimer.et.Hyper-V.quality: 1000
kern.eventtimer.et.Hyper-V.frequency: 10000000
kern.eventtimer.et.Hyper-V.flags: 6
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.LAPIC.quality: 100
kern.eventtimer.et.LAPIC.frequency: 100426660
kern.eventtimer.et.LAPIC.flags: 15
-------------------------------------------------------------------------------
I hope you see something unusual that could be changed to solve the problem.
Kind regards,
Gordon
--
Gordon Bergling
Mobile: +49 170 23 10 948
Web: https://www.gordons-perspective.com/
Mail: gbergling at gmail.com
Think before you print!
More information about the freebsd-hackers
mailing list