OK, I'm embarrassed to ask such a newbie question, but ... here goes.
I run a small departmental POP server at work. It serves maybe, oh, around
70-100 people or so (just guessing). (So, to get ahead of myself a bit,
we don't really have enough people - read: entries in "/var/mail" - for
me to think that going to some two-level hash directory setup in the
spool will help me with my problem very much. Read on ... )
It's running Qpopper 4.0.4 on a SPARCserver 20/71 with 128 Mbytes of RAM.
(Yes, I know. It's vastly underpowered.) running Solaris 7 11/99.
Under "normal" circumstances, the machine isn't really loaded. Relatively
speaking, POP usage is somewhat light.
But we have these few recalcitrant users who don't seem to know that "Keep
Messages On The Server" is bad. Really Bad. Especially when these few
people have mail spool files that are over 50 Mbytes in size. Some of
them even closer to 100 Mbytes (or over).
Naturally, every time these people POP in, the system goes into complete
I/O and CPU starvation mode as all cycles get used up copying their huge
mail spools to /var/mail/.luser.pop and then back again to /var/mail/luser.
We have a 500 MHz Sun Blade 100 with 1 Gbyte of RAM running Solaris 8 2/02
in the on-deck circle. It'll run a full-fledged POP/IMAP/WebMail server
with SPAM filtering, yadda yadda. But I haven't had time to get that
running yet - too many other fires to put out first. (Always the story,
isn't it?)
In the interim, are there any steps I can take with Qpopper 4.0.4 to
address this copy-to-.luser.pop-and-back-to-luser spool-file overhead problem?
Thanks in advance.
- Greg
