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