Date: Thu, 13 Mar 2003 14:27:42 +1300
To: <[EMAIL PROTECTED]>
From: Simon Byrnand <[EMAIL PROTECTED]>
Subject: Re: Avoiding copy-to-.luser.pop-and-back-to-luser spool I/O overhead?
At 12:23 12/03/03 -0800, Greg Earle wrote:Chris Shenton wrote:
> Greg Earle <[EMAIL PROTECTED]> writes:
>
>> 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).
>
> IMHO users do this not because they're trying to be butt-heads, but
> because they're trying to get work done. If their mail is sitting on
> their desktop at work, they can't access it on the road. etc.
The small group of recalcitrants is made up of a couple of people that might fit that category, but the others are just lazy non-mobile astronomers :-)
>> 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.
>
> Is this just when a user deletes a message? Or even when they just
> read a message (does the pop server have to touch the message content
> to update attributes like Status?). Either way, expensive I admit.
I'm not sure - all I know is that when I'm actually watching, the load average jumps up to 3 or 4, I clamp a truss on the qpopper processes and sure enough, they're doing the luser -> .luser.pop -> luser copies. Then I start to get complaints from others about how "the POP server is sluggish".
I see the same problem from time to time - on a PIII-800. A user accessing a spool file >50MB causes IO starvation while the copying is going on and the load average shoots up, making the machine quite sluggish. If you find a solution I'd be interested to know what it is....
Just looking at the possibility of using "server mode" for qpopper to solve the above mentioned problem, but would I be right in thinking that its then unsafe to have uw-imap providing imap access to the same mail spools ?
In server mode, does qpopper lock the mail spool the entire time the pop3 session is open ? Presumably if it did it would cause procmail to have to wait to deliver a message while a users spool is open ?
Anybody have any stories to share ?
Regards, Simon
