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".
> If the spool and temp file are on the same filesystem, you should be
> able to avoid the "copy" back to the original file: a UNIX rename()
> should be fine and is a "atomic" under UNIX (is a single fast
> operation, either succeeds completely or fails completely). So you
> avoid the second block-by-block disk read and write which hits the
> same disk twice for every block. Should help performance. But I don't
> know if the code works this way or not.
I don't think the code works that way, from what I've seen. It would
definitely help if it was just doing a rename() from luser to .luser.pop -
half the disk I/O would go away :-)
Anyway, I've found an extra spare 9 Gbyte SCSI disk lying around, so I'm
going to add that to the external bus and build 4.0.5 with the temp/cache
options (pointing them to the spare disk) Gregory Hicks suggested yesterday
and see how it goes, once 4.0.5 is out officially ...
- Greg
