Subject: Re: explaining TOP memory output and constant 1.0 load averages
To: None <netbsd-users@netbsd.org>
From: Mark Cullen <mark.r.cullen@gmail.com>
List: netbsd-users
Date: 07/19/2006 08:47:30
Johnny Billquist wrote:
> I just don't agree with your conclusions.
> No, I'm not short on RAM. And no, more ram don't solve every problem.
> A typical case of this is when much of a large file system is run 
> through once. This will fill up the caches with lots of data that will 
> not be referenced again, over and over again pushing out executable 
> programs from memory, which will be referenced again.
> 
> And my systems are not starved for I/O throughput, the problem is (was) 
> that programs got way too little memory, and caches way too much. There 
> is no I/O throughput in the world that will help that situation, and 
> memory wise it will not start to be acceptable until you're getting 
> close to as much memory as you are using disk.
> Not either a very likely, nor sensible scenario I think you would agree...
> 
> I find it just silly to say that my problem is that I have too little 
> ram, when obviously the system was very zappy before the new vm system 
> came into place, and the system was very zappy once again, once I 
> changed the vm tuning parameters.
> To suggest, in such a situation, that the problem is that I have too 
> little memory is on the verge of offensive.
> 
> I thought it was companies like Microsoft who used that excuse and 
> answer to all performance problems. It saddens me that the same 
> philosophy have come to permeate this place as well.
> 
>     Johnny
> 
> 

I think I'd have to agree. I'm really not really seeing how the very 
little swap I am using would cause me to have a ~1.00 load average at 
all times. I'm sure I am not CPU limited, as it's nearly always 100% 
idle (which just makes the 1.00 load average odd if you ask me), and the 
disks are also nearly always idle.

Johnny, is there any chance of going over what you actually changed to 
solve your problem? I've tried messing with the system vm. parameters 
but it hasn't really made any difference.

---
vm.loadavg: 1.33 1.36 2.08
vm.nkmempages = 32768
vm.anonmin = 10
vm.execmin = 10
vm.filemin = 20
vm.maxslp = 20
vm.uspace = 16384
vm.anonmax = 95
vm.execmax = 30
vm.filemax = 75
vm.bufcache = 15
vm.bufmem = 37070848
vm.bufmem_lowater = 4984320
vm.bufmem_hiwater = 39874560
vm.idlezero = 0
---


-- 
Mark Cullen <mark.r.cullen@gmail.com>