Hi, First, thanks to all fo you for the helpful tips and tricks.
The CPU load decreased a lot. #1 issue was the large rules.ima per domain which uses more CPU power for parsing the rules. I think the files size should be below 100K. Running MessageSniffer as a service and in persistent mode is also important. I applied this also on some customers servers. It saves about 3-5% CPU Power. Using internal DNS is also important and gives a bit more overall performance. After decreasing the default value from "skip list" (SMTP) from 500 to 50, the system released another 1-2% CPU Power. It looks like, that reading this data needs more Power compared with a DNS lookup. This is strange Voodoo. I also spend some time to over the DNSBL which i'm using. Surprise, surprise it needed some housekeeping. DNSBL1=spamhaus,10,sbl.spamhaus.org DNSBL2=dsbl,10,list.dsbl.org DNSBL3=njabl-dnsbl,10,dnsbl.njabl.org Spamhaus works together with dsbl.org and njabl.org. Using "xbl-sbl.spamhaus.org" together with the other two will cause redunant lookups and will also gives double counts. So, change it to sbl.spamhaus.org and use also dsbl.org and njabl.org. Also possible to use is pbl.spamhaus.org. This a "policy block list". First i have to learn, what this list is all about. At first sight, it has to many "caution" in the description.... DNSBL4=abuseeat,10,cbl.abuseat.org DNSBL5=spamcop,10,bl.spamcop.net DNSBL6=ahbl-dnsbl,10,dnsbl.ahbl.org DNSBL7=ahbl-rhsbl,10,rhsbl.ahbl.org DNSBL8=fiveten,10,blackholes.five-ten-sg.com DNSBL9=sorbs-http,10,http.dnsbl.sorbs.net DNSBL10=sorbs-socks,10,socks.dnsbl.sorbs.net DNSBL11=sorbs-smtp,10,smtp.dnsbl.sorbs.net DNSBL12=sorbs-web,10,web.dnsbl.sorbs.net DNSBL13=sorbs-spam,10,spam.dnsbl.sorbs.net DNSBL14=korea,10,korea.services.net DNSBL15=swinog,10,dnsrbl.swinog.ch DNSBL16=manitu,10,ix.dnsbl.manitu.net DNSBL17=uceprotect1,10,dnsbl-1.uceprotect.net These are the other DNSBL i'm using. It is important to check the several DNSBL from time to time if they are still alive. DNSBL15 to DNSBL17 are swiss and german blacklists. I don't know, if it makes sense to use them in the USA. dnsrbl.swinog.ch is quite good and the guys are updating the data all the time. Mit freundlichen Grüssen ---------------------------------------------------------------------------- ------- Merlin Consulting | Martin Schaible Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch Support: support.merlinconsulting.ch GPS: N47 20.235 E8 34.226 ---------------------------------------------------------------------------- ------- News - Unsere Produkte: .:. Ipswitch Premium Partner .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail .:. Brainware Columbus Software Management .:. NOD32 Antivirus System .:. NewAtlanta BlueDragon .:. Kiwi Syslog Monitor .:. Paessler Network Monitoring .:. SmarterTools ---------------------------------------------------------------------------- ------- > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Len Conrad > Gesendet: Dienstag, 13. März 2007 22:11 > An: Imail_Forum@list.ipswitch.com > Betreff: Re: AW: AW: [IMail Forum] Mail-Server on heavy load > > > >It's Compaq DL-360, which have only two disks. I don't see > the benefit to > >have the spool files on the same Array but in on a different > partition. > >Makes this really a difference? > > When a partition has X amt of used space plus X+ amt of free space, > the defragging is much faster and more complete. Of course, a spool > partition should be nearly always empty as the msgs transit the > partition briefly. > > Same is true of any partition, eg, the mail store partitions. > > Another advantage of having an IMGate type of MX/outbound gateway ( > vs trying to do everything on one box) is that the Imail outbound > msgs are always delivered in a couple seconds to IMGate, which does > all its own DNS lookups+timeouts, plus SMTP delivery attempts, + > timeouts, + deferrals/re-tries, and has much superior logging > than Imail. > > Len > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
