[clug] kernel options

[Andrew]

Hello again!
                   Thankyou very much for the advice :) - Very very helpful.

  I haven't been to a clug meeting for a while.... Are they still held 
at the Comp Sci. building at the  ANU?

Cheers,
          Andrew.


Matthew Hawkins wrote:

>Andrew said:
>  
>
>>Hi Matt!
>>            Thanks - i'll try using resierfs.... I have only been using
>>
>>it on my desktop as I am yet to have the confidence to use it on a
>>remote server (they are co-located in Sydney) - so stuff-ups cost :(
>>    
>>
>
>Changing a filesystem format is a fairly drastic change.. though it is
>possible to do it remotely (and somewhat ego-stroking in a geeky kind of
>way) if I were to recommend anything it would be a) have an admin onsite
>and b) kill anyone who even breathes the wrong way on your backup
>tapes/cds/etc until the system is restored to working order ;)
>  
>
>>So I shouldn't really bother looking at the max-files in the procfs at
>>all? Or should I bump it up too?
>>    
>>
>
>If you're getting the "too many open files" issue, there's only two ways
>to solve it.a) stop utilising so many file descriptors
>b) increase the limits imposed on processes in this regard.
>Changing filesystems isn't going to help you one iota.  (it may give you
>other benefits, for example journaled (meta)data, hashed dirents,
>performance, extended attributes, etc. which may or may not be of any use
>to you).
>Note most distros will let you alter procfs settings on boot time via
>/etc/sysctl.confso if you're getting this problem, that's probably the best place to fix
>it (you can have sysctl(8) update settings from this at run-time, no need
>to reboot).  My suggestion is you max it out, let the system get into
>normal usage (let it go for 24 hours or so) and then see how much is the
>maximum you really need, then drop the number back down.  Remember to
>factor in "peaks" into your analysis, so you're not setting the maximum
>too high simply because, eg, your web server got slashdotted.  The
>trade-off as far as I've seen is basically how well the hardware can cope
>with the value you set it to.  There's benefits to keeping it low, for
>example if your server does get slashdotted you don't necessarily want to
>have it attempt to cope with that kind of load simply because you've given
>it enough rope to hang itself with.
>  
>
>>Do you have anywhere to point me for reading on this matter too? (I
>>would like to learn more).
>>    
>>
>
>I've found experience to be a pretty good teacher.  Don't get too hung upandrew at donehue.net
>on so-called performance tuning.  There's very very few applications where
>its necessary.  Do you really want to spend $300 of your employers time
>and maybe a new resource or two (books) on creaming an extra 5%
>performance out of the existing system, or would you rather spend that
>$300 on a new CPU which is going to give a 50% (or more) improvement?On the file-max setting, basically its a matter of knowing what's running
>on your system (hey, I have a web server, mail server, ftp server - and
>they get busy sometimes - these are probably going to chew some fd's for
>the socket connections) and hence keeping an eye on file-nr, knowing that
>you've got certain limits imposed (whether it be the defaults from your
>distro install, or others you have imposed since then).  Graph it over
>time if you like - SNMP and the mrtg utility are very useful - and watch
>the trends.  Keep in mind what's happening around the times of any
>fluctuations - eg a new release of SLiRP was always a "fun" time to be
>logged into the UCNET server ;)  Plan ahead - where do you see your
>network going?  What's going to become an issue, and how can you mitigate
>that now?For example, when I worked at Goldweb Internet I had grand visions of
>servicing hundreds (thousands? millions?) of dialup customers, even though
>at the beginning it was more like 30.  But that many dialup users would
>mean either a *lot* of servers with multiport serial cards and a very
>noisy server room, or using some embedded access device (Portmaster, MAX,
>AS5x00, etc).  How does this affect authentication?  Do I want to rsync
>massive passwd files, use NIS, simply keep small local passwd files and
>give dedicated lines?  In the end I ended up implementing RADIUS, finding
>a server that was compatible with the popular embedded access devices AND
>a getty replacement that could be used on the existing server for the
>multiport card.  Come the time when we had multiple systems and access
>servers and hundreds of customers, Shit Just Worked (tm).  Real plug &
>play.  Did we need RADIUS at the time I did it?  Heck no.  But I learned
>lots of stuff about it and related subjects, made contacts, even helped
>others who were just a little behind me in the process.  And as I said,
>come the time it was necessary, it was already there, working, and well
>tested.I digressed a bit, I guess in short - take things one at a time, read man
>pages and any kernel Documentation/ and the HOWTOs and stuff, find a
>related mailing list, and use google :)
>(... and come to CLUG meetings and get scared by the mad driving skills of
>a carload of geeks with a carload of pizza navigating Acton<->Dickson in
>-4C temps ;)
>  
>