On Sat, Oct 26, 2002 at 07:25:02PM -0700, John Rudd wrote:
> > >option? We get enough pop processes on our server that having config
> > >files creates a resource contention problem on the disk where the config
> > >file lives, so config files == bad.
> > >
> [snip]
> > >
> > >Ideally, every config file option would have a CLI equivalent.
> >
> > There are provisions for having every user using a separate configuration
> > file. But really I have to ask... what is wrong with using a config file
> > instead of command line switches?
>
> I trimmed my part of the above down because the answer to your question
> was in my message. To explain it a little more, if a popper starts up and
> then immediately tries to open a config file, it's going to hang while
> waiting for IO. If you've got 15000 users, that can build up. For example,
> in the last two days, when I forgot about this issue, I accidently enabled
> config files for the poppers, and I had, at some points, 6000 popper processes
> all sleeping on waiting to open their config files.
I am really a bit dubious this was the source of the contention,
unless you are running some unusual operating system, or there is some
other underlying bug. As Chuck Yerkes noted, if you have 6000
processes all opening the same file for read access, in most reasonable
versions of UNIX they should all be transparently reading copies from
the same disk buffer cached in the kernel's RAM.
However, I would expect 6000 popper processes all trying to update
files on the same partition would certainly hang up your system
regardless of whether they are reading config files or not!
> (limiting the number of
> processes only trades symptoms of "painfully slow pop processes that
> ultimately timeout" for "refusing connections" ... either way it's a problem,
> and neither one happens if you aren't using config files ... and in that
> case, the turn over is usually fast enough that the number of pop processes
> doesn't tend to grow past 1000 any way)
With 6000 processes, or even 1000, isn't your system swapping like
crazy at this point? Isn't the swapping more likely the source of the
troubles? Or contention to update the directory for the mail spool
files and/or recopy the mail spools?
> Part of it is "where does the config file live"? The default location is
> in /etc/mail/pop ... on the root disk, along with the sendmail config file,
> things like the nsswitch.conf, hosts.allow and hosts.deny, etc. Oh, and
> the password file. Things that get used A LOT.
Which means they shouldn't be loaded off the disk, they should be in RAM
already.... Something's not right here.
> To a certain extent, the
> problem can be solved by putting lots of things on different disks ... but in
> the most extreme case, that starts to look like a disk for just /etc/mail/pop.
> That doesn't scale much better than having everything in /etc.
>
> In contrast, if the config files don't exist, the IO process is much faster,
> and the poppers barely hang.
I would look also at whether there is some value in the config file,
other than disabling the cache file, which is causing a problem? Or
now that I think about it, whether disabling the cache file is itself
the source of the problems?
But, in order for that to happen, you have to be
> able to specify everything on the command line (or in the configure script, but
> that can be a little too static for my tastes, I don't want to have to
> recompile just to change every little decision).
I can give you some help on this part - all of the command line flags
and the config file options are controlled by sets of tables and case
statements in the C source. If you're willing to create yourself a
patch for the source, you can easily create new command line flags for
your installation to add remaining config file options to the command
line.
Look in popper/pop_config.c and popper/pop_init.c for how to handle
it - read through and grok how the existing command line options are
handled and you should be able to easily make this a command line
option.
I just have a nagging feeling that you have other problems on this
server which you might not have characterized yet.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
"As for yourself, ... I am well disposed to hope you may hitherto have
escaped many Vices of your Country. But by what I have gathered from
your own Relation, and the Answers I have with much Pain wringed and
extorted from you, I cannot but conclude the Bulk of your Natives to be
the most pernicious Race of little odious Vermin that Nature ever
suffered to crawl upon the Surface of the Earth."
- Jonathan Swift, _Gulliver's Travels_
