[clug] kernel options

[Matthew Hawkins]

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 up
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 ;)
-- 
Matt