On Tue, Nov 13, 2001 at 02:01:37PM +1100, David Nillesen wrote:
> Hi,
>
> We are looking at replacing the uw-imap package with qpopper to
> increase speed and efficiancy on our server, but when we went live we
> ran into a few issues.
>
> The server would happily answer requests for a while but started
> to choke with a buildup of popper processes that were hanging around
> after the user had closed the session. Users started to get the 'mailbox
> already in use' message.
>
> We were upto 450+ popper sessions active when there should only
> be about 40 concurrent users at any one time. uw-imap's ipop3d works
> fine on the same system but is slow.
Shooting from the hip, this sounds like a problem with it not getting
a HUP signal when the session goes away unexpectedly.
> Qpopper was running in server and standalone mode. It was
> compiled with the following options:
>
> ./configure --enable-spool-dir=/var/spool/mail --disable-check-hash-dir
> --disable-old-spool-loc --enable-log-login --enable-server-mode
> --enable-shy --enable-standalone --enable-uw-kludge --enable-specialauth
>
> It compiled cleanly.
>
> I've moved the source over to a debian linux system where it
> compiled cleanly and ran without the same errors. When tested on our
> production server we were using live users, when running on the test bed
> we used the 'postal' package and the executable 'rabid' to generate an
> artifical POP3 load.
> There are 17000 accounts on the production system and approx
> 10000 accounts on our test bed server.
>
> The other thing worth mentioning is that our /var/spool/mail is
> on a very very inefficient raid setup and it bottlenecks on IO a fair
> bit. However ipop3d seems to cope ok at the moment, albeit a lot slower.
Probably not related, would be my guess.
> Any suggestions would be most welcome. Especially if anyone
> could suggest other areas to check.
>
> So far, my own thoughts point to a few areas but I dont know how
> likely my guesses are:
>
> 1: Filesystem is too slow to release locks.
> * But ipop3d works, perhaps due to the fact it is slower?
> * is it possible to just use fcntl locking without dotlocking so
> as to move the locking off the filesystem? I cant modify the
> source code, due to maintainence problems.
Offhand, I don't think the problem is on the locking side. (You
probably need the dotlock to keep mail delivery from colliding with
mail retrieval, unless you can also change postfix or your delivery
agent to do only fcntl locking on the spool.)
> 2: Tru64 libraries / OS is slow to release fcntl locks and / or
> sockets.
> * A friend of mine who has used unix since moses built the ark, told
> me that some unix's (unii??) are very slow to release sockets.
unices ;-) (a la index, indices)
> Would this give me the symptoms we are experiencing? The
> linux testing would seem to indicate that it's OS based...
This sounds closer to the mark - I would guess specifically that your
qpopper processes are clinging to the broken connection in hopes that
it will return. Try seeing if TruUnix supports the following sysctl
parameters, and if so, query them:
net.inet.tcp.keepinterval integer yes
net.inet.tcp.maxpersistidle integer yes
These are very OS-specific, but if available, with much consulting of
man pages and documentation, may tell you how your UNIX handles
detection of idle sessions. If not, it may at least point you in the
right direction.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
