Hello, I had the same problem at the beginning of SoBig and similars which were filling my queue. At that point I had at least 20000 messages in the queue in the peak time. I came with the following optimizations:
1. Mount the partition with folders and mail queue with noatime flag. That will speed up mailq. In my case mailq took about 10s to run with 20K messages. 2. Lower the time for messages to stay in queue: queuetime. I've set 24h. 3. I've made a short perl program that will parse the queue and help you cancel messages (see attachment). Just run it with -c 10 and it will show the top 10 messages. Remove them from the queue (if it is spam or bounce) with -r flag _BUT_ if they are bounces or spam put them also into bofh file. 4. Remove any quarantine actions from RAV. It's just killing your disks and I do not think it is usefull (use it only for debug). And disk bandwidth is what courierd is laking to parse the disk queue faster. 5. DO NOT bounce any message from RAV (just do not inform anyone!). Drop all high possibility spam and virus messages (return address of sobig is broken anyway). If you do that I promise you: # time mailq | tail -n 2 166 messages. mailq 0.01s user 0.02s system 108% cpu 0.028 total tail -n 2 0.00s user 0.00s system 0% cpu 0.020 total PS: In case you see two messages, the first one was sent from an address which is not subscribed to this list so it may not pass moderator approval. On Sat, Sep 06, 2003 at 10:33:21AM -0700, Colin Dick wrote: > Hi, > I am trying to use courier-mta (courierimap/courierpop), > squirrelmail, spamassassin (w/razor2) and RAV antivirus as a spam/virus > reduced service to my customers. > In testing everything worked great. Now that I have about 1000 > users on the box, I am running into mail delays (up to 3 days). > > As far as I can tell, I am getting more mail than I am able to > process through the memory based queue during peak times and the messages > are getting dumped to the disk based queue. I have many message (mostly > bounce messages to spoofed senders) that are old and are taking up the > space in the memory queue when it reloads due to my queuefill value (15m). > The legitimate local deliveries never get a chance. I have tried playing > with queuehi/queuelo (2500/2000) but it doesn't seem to matter how many > messages I allow into memory, the system still can't keep up. > > I have a couple ideas but need some help in implementing: > > How would I reserve some space in the memory queue for new local > deliveries? In other words prioritize for the local users on the box. I > have currently written a program to dump the mailq (which takes 8 or more > hours), parse it for localusers and flush specific messages. However, > when the memory queue is full, I don't think the messages can even be > forced to flush. > > How can I discard bounce messages. In exim, there is a setting called > ignore-errormsg-errors-after or simply ignore-errormsg-errors. This > really helps with bounce messages to spoofed (invalid) senders. Again, I > have currently written a script to parse the mailq for specific addresses > that I can run cancelmsg on. This way, I can toss 'batches' of messages > once I determine the return address of any particular spam run. > > Writing my own scripts is fine, however, I am sure there is a > better way since this must be a common issue. Also, my scripts rely on > the mailq output (which takes forever), so my forcing of local mail can > only be as quick as the mailq results. > The computer is a P4 1.60GHz (cpu MHz : 1615.935) running on > RH9.0. We recently doubled the RAM from 512 to 1G which helped the speed > of Squirrelmail, however, the queue just won't process fast enough. > Hopefully that is enough information to get a couple of tips. Or > perhaps someones document on how they optimized similar setups. I look > forward to any replies (as do my users.... yup, I have already turned this > into a production server and the delays have been going on 3 weeks now). > -- Mircea Damian Data Network Manager - Internet & Data E-mail: [EMAIL PROTECTED] Astral Telecom Bucuresti ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users