🚀 go-pugleaf

In article <15444@netnews.upenn.edu> litwack@operations.dccs.upenn.edu (Mark Litwack) writes:
>In article <9475@june.cs.washington.edu> richk@june.cs.washington.edu (Richard Korry) writes:
>>behavior: jobs that are swapped (ps stat = W) get placed on the
>>run queue (ps stat = RW) but never seem to run. the load average shoots
>>up but nothing is actually executing. The only fix has been to reboot.
>>Anyone else ever seen this?
>>	rich
>
>  Yes, I'm glad (in a way) that we aren't the only ones.

We have seen something like this too - I happened to catch a "sysmon"
of what it was doing. I had a program running that had dynamically
allocated large amounts of memory, in little bits at a time. At some point
the program wanted wanting "just a little more memory" , say 200 bytes.
The kernel would SWAP the entire working set out to disk, and then 
fault it all back in a little shred at a time until we finally get back 
to asking for the SAME "little bit of memory", and then this all 
happens again, ad infinitum.  Load average goes nuts. May or may not be 
able to suspend or kill the job.  May lock up other system resources too.  
Often times, the amount of free memory was still a Meg or so...

This was apparently "fixed" when we upgraded to the latest 3100 rev of
Ultrix, but the behavior persits. If the memory allocation is done in
all big chunks (totally to the same amount as before, but not in little
chunks), then everything seems to be OK.

Note that the behavior I describe will occur even if I am the ONLY user,
and (other a few of the background processes) am the only runnable process.
Working off of an NFS-mounted partition seems to make it worse, sort-of.

Scott Wilson
University of New Mexico
Center for High Technology Materials
Albuquerque, NM 87131
(505)277-0780