larry@nstar.UUCP (Larry Snyder) (01/01/90)
Since ISC is distributing the same kernel configurations for 4 and 8 megabytes - what are most of you using for parameters with 8 megs in your box? I've changed NBUF to 900, NINODE, NS5INODE and NFILE to 600 and NCLIST to 300 - and am wondering what else if anything should I change? thanks and happy new year! -- Larry Snyder, Northern Star Communications, Notre Dame, IN uucp: root@nstar -or- ...!iuvax!ndmath!nstar!root
bill@ssbn.WLK.COM (Bill Kennedy) (01/01/90)
In article <511111@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >Since ISC is distributing the same kernel configurations for 4 and 8 >megabytes - what are most of you using for parameters with 8 megs in your box? It really depends on what the box is doing. It's not a safe assumption that more memory means just up everything by some amount. If you have a lot of tty activity but not much file activity then NCLIST is a good thing to raise. Probably the best way to do it is to run the system activity reports and see how you're doing with how you're tuned right now. You can learn some pretty interesting things by watching the results in the sar's. One thing I learned was that the X-windows xload is a nifty and colorful display that's fun to watch. I'm not sure what it's plotting, but it's not the system load... >I've changed NBUF to 900, NINODE, NS5INODE and NFILE to 600 and NCLIST >to 300 - and am wondering what else if anything should I change? If you have a UPS you can consider changing NAUTOUP. You'll have to go edit the mtune file to permit a value longer than 20sec, I set mine at 120sec. That calms down the buffer flusher some and it's quite safe if you are certain you aren't going to lose power suddenly. My system has a lumpy uucp load and very little local activity so I used 1000 for NBUF, same as Larry for NS5INODE/NINODE/NFILE. Because of the uucp load I ran NCLIST up to 400, NPROC to 275, NOFILES to 64 and ULIMIT to 4096. At sign on my system reports 9203712 bytes of 10092544 available. The sar's show that the buffer cache gets a 96% or better hit rate on reads, 76% or better on writes. I can make the system start swapping if I run a couple of pathalias' at once, but compress seems pretty even tempered (and a lot faster than when the system had 6Mb). As expected, both troff and tape back up really slow it down, but my suspicions about memory vs math chip were confirmed. There was a lot of performance to be gained for fewer dollars by adding memory. >thanks and happy new year! Ditto from Pipe Creek, TX! >Larry Snyder, Northern Star Communications, Notre Dame, IN -- Bill Kennedy usenet {attctc,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill