Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!goanna!minyos.xx.rmit.oz.au!godzilla!mg
From: mg@godzilla.cgl.rmit.oz.au (Mike Gigante)
Newsgroups: comp.sys.sgi
Subject: Re: itty bitty IRIX questions
Message-ID: <mg.675842217@godzilla>
Date: 2 Jun 91 05:56:57 GMT
Article-I.D.: godzilla.mg.675842217
References: <9106020322.AA12664@crow.omni.co>
Sender: usenet@minyos.xx.rmit.oz.au (Njuiz noveles nova newes)
Organization: RMIT Computer Centre, Melbourne Australia.
Lines: 24
Originator: mg@

rpaul@crow.UUCP (Rodian Paul) writes:

]Randy Carpenter asked:

]] |   2.) Why does ps(1) take so long every once in a while but then
]] |       has good response at other times.

]Dave Olson answered:

]] If you change /unix, or remove /tmp/.ps_data, the file gets re-created,
]] which takes a while.  After that ps runs faster.  Basicly it saves ps
]] having to grub through the kernel symbol table on each invocation.
]] 

]Myself and others here have also noticed this problem. We don't dick
]with the kernels that often and to my knowledge nobody deliberatly 
]trashes /tmp/.ps_data. I'm afraid I don't think that the above 
]answer quite explains why the response is often so slow. The odd 
]thing is that the response problem doesn't seem tied to the load-average
]on the machine.

The way I have figured it is that the first time each day it is really slow
while the other times ity is fast. It may be either date/time based as I
speculate, or it may ignore /tmp/ps_data if it is older than X (for some X)