Gary V wrote: > On 4/4/09, Giuseppe Ghibò <gh...@mandriva.com> wrote: > >> In amavisd-new documentation README.postfix (version 148, >> BTW, the release online is outdate, as reports version 122 >> see http://www.ijs.si/software/amavisd/README.postfix) >> there is reported that using amavisfeed_destination_concurrency_limit = XX >> is an alternative way to master.cf for controlling the maximum numbers of >> concurrent processes (which should be in sync with amavis $max_servers). >> Indeed I found that >> the number of concurrent lmtp processes named amavisdfeed >> exceed 1 unit the number in amavisfeed_destination_concurrency_limit. E.g. >> if I have amavisfeed_destination_concurrency_limit = 2, I get 3 >> amavisfeed lmtp processes running, >> if I have amavisfeed_destination_concurrency_limit = 1 I get 1 lmtp >> process running and so on. >> > > I may be misunderstanding, but are you looking at the number of > amavisd proceses running? If $max_servers is set to 2, you get one > master and two child processes. Changing > amavisfeed_destination_concurrency_limit limits the number of messages > that Postfix will ask amavisd-new to process concurrently (not the > number of amavisd processes that run). The number of child amavisd > I'm looking not at the number of amavis processes but at the number of postfix lmtp processes running under the name amavisfeed, or to be precise at the output you achieve from ps -ef|grep amavisfeed which gives usually, entries like:
postfix 29543 2826 0 10:03 ? 00:00:00 lmtp -n amavisfeed -t unix -u -c -o lmtp_data_done_timeout 1200 -o lmtp_send_xforward_command yes -o lmtp_cache_connection no -o max_use 20 according that the name choosen is amavisdfeed. Indeed if you set the number of processes to 2 in master.cf you get exactly always 2 lmtp process to feed amavisd while setting in amavisfeed_destination_concurrency_limit, you get one more, which IMHO could lead to timeouts (which is likely to occur if for instance you don't set the limit and leave it to default, which is 100). >> > > It would be rare to use 1. If we are talking about your server that is > a dual quad Zeon with 12GB ram, I would start out with something more > like 20 or 30. I noticed in another thread that you are experiencing > high latency due to network tests. Network tests are a vital part of > spam detection and spamassassin does not work effectively without > them. Most of the delay is caused by waiting for answers from remote > servers (and getting timeouts for various reasons). To help with that, > an effective thing to do is to increase concurrency by increasing the > number of processes ($max_servers and complimentary > amavisfeed_destination_concurrency_limit) up to a certain sweet spot, > where you are processing as much mail as quickly as possible. Setting > the number too high makes a mess and greatly decreases performance. > > http://www.ijs.si/software/amavisd/README.performance.txt > > Also, it's highly beneficial to run a local DNS cache. This increases > speed and effectiveness of network tests. > > Well, I already was using a standalone DNS with bind and forwarders (unless you mean something other), but I didn't get significative increasing between two consecutive runs of spamassassin -t -D, I get always around 12-15s, which IMHO is too much. With spamassassin -t -D -L the lowest is around 2.6s, which I think it's high too (at least compared to older SA versions). The timing sound like this: [1536] dbg: async: timing: 0.007 . dns:TXT:150.21.1.189.cbl.abuseat.org. [1536] dbg: async: timing: 0.009 . dns:TXT:150.21.1.189.bl.spamcop.net. [1536] dbg: async: timing: 0.010 . dns:A:myhostname [1536] dbg: async: timing: 0.010 . dns:MX:my_hostname [1536] dbg: async: timing: 0.012 . NS:from_hostname [1536] dbg: async: timing: 0.013 . NS:someotherhost_appearing_in_mail [1536] dbg: async: timing: 0.013 . DNSBL:multi.surbl.org.:other_hostname ... [1536] dbg: async: timing: 0.488 . A:ns4.doubleclick.net. [1536] dbg: async: timing: 0.488 . A:ns3.doubleclick.net. ... [1536] dbg: async: timing: 0.510 . DNSBL:multi.surbl.org.:someotherhost_appearing_in_mail [1536] dbg: async: timing: 7.986 X DNSBL:sbl.spamhaus.org.:<IP1> [1536] dbg: async: timing: 7.986 X DNSBL:sbl.spamhaus.org.:<IP2> [1536] dbg: async: timing: 7.986 X DNSBL:sbl.spamhaus.org.:<IP3> ... [1536] dbg: async: timing: 10.369 X dns:A:<IP4>.sbl-xbl.spamhaus.org. [1536] dbg: async: timing: 10.371 X dns:A:<IP4>.zen.spamhaus.org. so I see much time is spent on spamhaus.org. Is that working or overloaded or maybe disabled? Why in that case the "caching" doesn't seem working? Thanks. Bye Giuseppe. ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
