* On 2003.03.12, in <[EMAIL PROTECTED]>, * "Simon Byrnand" <[EMAIL PROTECTED]> wrote: > >>> > >>>> 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).
Forgive me for jumping into the middle of a discussion here without reading all the background. I just joined the list, and had planned to wait and get cozy before posting, but what I wanted to post about is immediately relevant to this issue. > >>> 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 > >>:-) That's what we've found, too, on both counts. A lot of our users have legitimate needs for leaving mail on the server, so we don't want to turn it off -- but some of those, and a lot of the others, are just oblivious or obstinate. > >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 We've enabled server mode, but it had limited effect -- there's still a maildrop copy for each connect. To solve the trouble for the longer term, and in a flexible way, we went another route: we've patched qpopper to implement a kind of rate limiting on heavy users. In essence, what we're now able to do is to enforce a certain delay between POP checks, and to make the length of this delay variable per user, dependent on how much mail is in their inbox. We can adjust the aggressiveness of this penalty on the fly, since it can be tuned in the popper.conf or on the command line. When we have strange server trouble we sometimes ratchet it up a little. This lets us continue providing service, just on a reduced schedule, while we find and implement other ways of improving performance. I've written up a web page describing the patch and the associated query/reset tool. Please feel free to download and have a look. This is not supported by the Univerity of Chicago, of course, but we've been using it on our central e-mail server for about 10 months, without revision, and without regret. http://home.uchicago.edu/~dgc/sw/qpopper/ At one time I produced usage tables indicating something like that 10% of our users were using 60% of server I/O resources, solely through the frequency of their mail checks. This patch went a long way toward bring those users back in line, without penalizing users who just leave a little mail on the server. The biggest social cost to us was that the POP authentication failure caused Eudora to forget people's passwords, but since we encourage users not to make Eudora remember their passwords anyway, that was a failure we could easily live with. -- -D. [EMAIL PROTECTED] NSIT University of Chicago "The whole thrust of the text adventure was one picture was worth a thousand words and we would rather give you the thousand words." - Dave Lebling, Implementor
