> 	You suggest that raid-frame is a no-no on heavily worked filesystems.  
> Is this due to memory constraints or cpu constraints?

i think slow writes is a problem (RAID-5)

> -Brian
> On Feb 21, 11:53am, <sudog@sudog.com> wrote:
> } Subject: Re: About NetBSD server tuning!
> } 
> } > Are there any syslog entries like "proc: table is full - increase
> } > kern.maxproc or NPROC" ? Couple of subsystems report when they
> } > reach the limit of resources and hint what should be raised.
> } >
> } > You probably want to bump MAXUSERS to 64, too.
> } >
> } > Jaromir
> } 
> } There were, once upon a time, these problems. Currently I've got the
> } MAXPROC set pretty high to accommodate the vast hordes of people who
> } are nailing the sites. For instance, I've got
> } 
> } kern.maxproc = 4096
> } kern.maxfiles = 8196
> } kern.nmbclusters = 8192
> } vm.nkmempages: 16280
> } 
> } Now this machine in particular has only 256M ram.. but perhaps x1.5
> } that in swap.
> } 
> } What I've noticed is that there are three thresholds that I'm
> } currently trying to "feel" out.
> } 
> } 1. The threshold of maximum processes the machine is sysctl'd to.
> } 
> } 2. The maximum number of apache processes/cgi processes, controlled by
> } shell ulimits, that the server software is currently limited to.
> } 
> } 3. The actual number of apache processes that apache limits itself to.
> } 
> } I've noticed some patterns.
> } 
> } #2 must not exceed #1-x% where x is some small single-digit number. If
> } it exceeds #1-x%, things choke and I need to reboot the machine. (This
> } load is driven mostly by users clicking and clicking and hitting
> } refresh etc.)
> } 
> } If #3 (and corresponding perl cgi children) exceeds #2, apache stalls
> } and is no longer capable of handling cgi. It must be SIGHUP'd to be
> } corrected.
> } 
> } It's a juggling act once the kernel is tuned to be capable of dealing
> } with the huge limits and doesn't panic any more under the loads.
> } 
> } Some guidelines I've been forced into finding out for myself:
> } 
> } 1. RAIDFrame is a no-no on the heavily accessed drives. The huge
> } volume of small reads and tiny writes that happen can only be handled
> } on a normal ffs-based partition.  Therefore in order to ensure minimal
> } data loss, regular backups must be made.
> } 
> } 2. With RAM at a premium, another balance must be achieved: That of
> } file system caching to actual RAM. I could increase the amount of
> } memory dedicated to file system caching; but this needs to be
> } considered in conjunction with how many users are connected at once.
> } Too much, and there's too much wastage and machinery isn't living up
> } to its potential. Too little and the users can starve the system.
> } 
> } 3. SCSI, SCSI, SCSI. Anything less and you're spinning your wheels.
> } Preferrably Seagate's new 15k Cheetah drives. Now those, are nice.
> } Quantum Atlas V 10k are nice too but hella loud. Sounds like a jet
> } fighter throttling up!
> } 
> } ------------***
> } 
> } I really need to figure out some specific equations to decide where to
> } set these limits..  do some testing or profiling to find out how long
> } on average each perl child takes, how much it accesses the disk and in
> } what patterns, and then how much the system can actually handle of
> } this..  how much users use the CGI as opposed to normal HTML links as
> } a ratio.. and work this into the daily traffic.
> } 
> } This is so complicated, I was hoping another user here could offer
> } some common server configurations based on available RAM and disk type
> } (IDE vs SCSI) that they've been able to work with and not have to
> } worry about things getting out of control.
> } 
> } Thank you for your time,
> } 
> } Sincerely,
> } 
> } Marc Tooley
> } 
> >-- End of excerpt from <sudog@sudog.com>
> 
>