From: lew.pitcher@digitalfreehold.ca   
      
   On Mon, 06 Jun 2022 15:04:46 +0000, S.K.R. de Jong wrote:   
      
   > I have a Slackware64 15.0 system on which I had several directories   
   > mounted by NFS from a remote system. That remote system was actually   
   > rebooted a few times - for maintenance purposes - but I was stupid   
   > enough not to unmount those directories in my system.   
      
   [snip]   
      
   > 	The system load has shot up to at least 4.00 ever since, even   
   > when, according to top, nothing much is going on in the system. I mean,   
   > I have a few things running, but nothing to justify that load: all the   
   > cores are at least 95% idle at any given time.   
   >   
   > 	I was able to unmount those NFS directories - forcefully, on   
   > occasion - and I was able to stop the RPC and NFSD daemons. However, the   
   > high load issue did not disappear.   
   >   
   > 	Anybody got any suggestions as to how to diagnose and solve this   
   > problem, without rebooting? top is not helping, and I see nothing   
   > relevant in dmesg, or any of the /var/log files. More precisely, there   
   > are relevant entries, but they are all old and not being updated - but   
   > the high load stubbornly remains.   
      
   I have no insights into your high loadavg problem. However, I do note a   
   suspicious co-incidence:   
   a) you have high loadavg, and   
   b) your system logs "are not being updated".   
      
   Perhaps you should investigate /why/ the system logs are not being   
   updated; this phenomenon might be related to the cause of your high   
   loadavg.   
      
   BTW, the getloadavg(3) manpage refers to the proc(5) manpage, and   
   according to proc(5), the loadavg figures represent "the number of   
   jobs in the run queue (state R) or waiting for disk I/O (state D)   
   averaged over 1, 5, and 15 minutes".   
      
   I note that you looked at top(1), presumably to see the runnable   
   processes; did you look to see the processes "waiting for disk I/O"?   
   If so, was there anything suspicious there? Perhaps a kernel module   
   or logging daemon that shouldn't have been waiting?   
      
   --   
   Lew Pitcher   
   "In Skills, We Trust"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)