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.
We were trying to run qpopper on an Alphaserver 1200, dual
400mhz cpu's, 1.5Gb RAM, 100Mb network connection, tru64 unix version
4.0f.
Postfix is our incoming mail server and it's using it's standard
mail delivery setup.
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.
I have tried the mailling list archives for this list and also
the tru64-managers maillist to no avail.
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.
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.
Would this give me the symptoms we are experiencing? The
linux testing would seem to indicate that it's OS based...
But these are just guesses at this point.
Any comments are most welcome.
Thanks in advance,
David N
System Administrator
University of New England
