On Wed, Oct 10, 2001 at 12:25:29PM +0100, [EMAIL PROTECTED] wrote: > Thanks for your reply which was most informative and set us here thinking. > > The main query was did your approach of copying temporary pop-drop files to > a different partition (and back) slow the process down at all ? Currently > our pop-drops reside in the users' home directory the same as their Mailbox > you see.
To answer your main question: No. I had *expected* that the total performance would decrease in server-mode, because the "fast-updates" option is ineffective when the two files are located on different partitions. In fact the reverse happened - performance went up and total load on our system went down, substantially. Eventually I figured out that the performance increase from two other factors more than compensated for this loss. The throughput when the spools must be copied is faster because the second partition is on a different RAID set, and this leads to more parallelized I/O during large copies (the system can be simultaneously reading one set of disks while writing the other set), but also it means much less disk head motion and seek delays, because it does not need to "swing" the heads from one part of the disk to another to copy a large spool file. (I've forgotten who, but someone else on this list pointed that out as a key factor in the performance analysis, thanks!) There's some emails from a month or so ago discussing this on the list. Summary: if you can put the temp files on a disk partition located on a physically separate disk or RAID set from the one where your spools are stored, your total POP throughput should go up dramatically. Qpopper is generally disk-bound on most systems. -- Clifton > At 10:24 09/10/01 -1000, Clifton Royston wrote: > > When I was reviewing it a month or two ago, I found a surprising > >scarcity of web information on setting up mail quotas; you'd think > >everyone would want to do it, but there's not much information out > >there, at least not that I could find in Google. I wanted to do it via > >file-system (kernel-level) quotas, but had to make sure that all > >components of the mail system would handle it well. > > > > There actually is one important Qpopper related fact for implementing > >mail quotas: > > > > If you implement quotas at the file system level, you want to > >configure Qpopper so the temporary pop-drop files are on a different > >partition from your mail spools, without user quotas. Otherwise, once > >a user hits their quota, they will be unable to pop their mail to > >reduce their mailbox below quota. > > > > That aside, quota enforcement is the work of the local mail delivery > >agent; that may be either your MTA, or delegated by the MTA to some > >other program. We use procmail for local mail delivery, and our > >testing showed that it was very quota-aware, and able to communicate > >over-quota conditions back to the MTA which invoked it. After a little > >tweaking on how our MTA reported these erorrs, I enabled and set user > >quotas on our mail spool partition two weeks ago, and have not had any > >problems with it so far. If users are near quota, any new mail coming > >in which would put them over-quota gets bounced back to the sender > >instead of being delivered. -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
