Bug 12979

Summary: Response time continually slows on idle machine, PIII processors on version 3.2
Product: Base System Reporter: Russell.Ingram <Russell.Ingram>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Russell.Ingram 1999-08-05 02:20:00 UTC
I have a Intel brand server machine with 2 - 500 Mhz Xeon processors one GigBYTE RAM, 4 Gig Swap, Adaptec 2940, Symbios controller (on board but disabled).  

With the GENERIC kernel fresh after install the machine slowed to a crawl after one day (mostly sitting idle). The next day it didn't respond within 5 minutes. A powerdown and reboot brought it back to life with the same results. The one unusual thing I saw with a "ps -axv" was that the rpc.statd took 262968 K BYTEs of virtual space (on my 2.6 systems this is 176 K Bytes). I compiled xperfmon3 and viewed what it would tell me and got nothing unusual even when things got slow. I can send a jpeg or gif of the xperfmon window. 

I generated an SMP Kernel and I'm seeing the same thing. 

What should I be using to see where the kernel is spending it's time.

I also have a Dell (PII with 128 M-BYTEs) running FreeBSD 2.6 that slows after about a week. However, all my system with 64 M-BYTES or less can run for months without problems. Neither of the larger RAM systems have the KERNEL option to say how much memory they have, but they recognize the RAM during boot.

Thanks Russ 
If you have problems with my NCR email address use rfi@home.com

How-To-Repeat: Leave the system on for a day. The system is idle most of the time.
Comment 1 Gregory Bond 1999-08-05 02:27:43 UTC
Russell.Ingram@sandiegoca.ncr.com said:
> The one unusual thing I saw with a "ps -axv" was that the rpc.statd
> took 262968 K BYTEs of virtual space (on my 2.6 systems this is 176 K
> Bytes).

This is normal behaviour for rpc.statd. It MMAPs a huge chunk (256Mb) of anon
memory but doesn't use most of it.  It is not the cause of the stated
performance issue.
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 01:04:35 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 3 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 01:27:39 UTC
State Changed
From-To: feedback->closed


The originator, in a private e-mail to me, indicated that he is no 
longer able to test against a newer version of FreeBSD.  It seems to 
me, the problem was most likely hardware related.