Hi Mark,

Thanks for clarifying the tests and how they sum up.

Actually I did'nt use Mail::SpamAssassin::BayesStore::MySQL but 
Mail::SpamAssassin::BayesStore::SQL

I have changed to use MySQL and will investigate if this has improved the 
TIMING-SA

Another issue might be, that I have changed to use a MySqlCluster setup using 
type=ncbcluster for bayes DB
This might also decrease performance. This will be the next issue I look into.

I do hope I can use the cluster based solution because this gives me a good 
fallback solution if one
Of the mysql servers fail.

I'll inform the list on whatever this will lead to 

Regards

Peter
                                
                
-----Oprindelig meddelelse-----
Fra: Mark Martinec [mailto:mark.martinec+ama...@ijs.si] 
Sendt: 17. februar 2011 20:55
Til: amavis-user@lists.sourceforge.net
Emne: Re: [AMaViS-user] TIMING-SA what does test_pri mean ?

Peter,

> I have just implementetd a new mailsetup based on postfix 2.7.0
> amavisd-new 2.6 and spamassassin 3.3.1 on ununtu 10.04 LTS
> 
> Somehow scanning is just to slow. I have the following in the logfiles (
> loglevel=2):
> 
> Feb 17 20:20:13 mxgw1.sdu.dk amavis[12250]: (12250-08) TIMING-SA
> total 80160 ms - parse: 3 (0.0%), extract_message_metadata: 29 (0.0%),
> get_uri_detail_list: 15 (0.0%), tests_pri_-1000: 6 (0.0%), tests_pri_-950:
> 1.32 (0.0%), tests_pri_-900: 1.42 (0.0%), tests_pri_-400: 76554 (95.5%),
> check_bayes: 76545 (95.5%), tests_pri_0: 3541 (4.4%), check_dkim_adsp: 166
> (0.2%), check_spf: 650 (0.8%), poll_dns_idle: 644 (0.8%), check_dcc: 238
> (0.3%), check_razor2: 1813 (2.3%), check_pyzor: 72 (0.1%), tests_pri_500:
> 5 (0.0%), get_report: 1.96 (0.0%)
> 
> and in here the test_pri which I don't know what is is consuming a
> resaonably amount of time.

The entries in TIMING-SA may overlap, so the sum of them typically
exceeds the total. As in the above case: the  tests_pri_-400 (76 seconds)
includes the bayes test check_bayes (76 s). So, the bayes test
accounts for all but 4 seconds in your case. The tests_pri_-400
can be disregarded.

> The overall is between 20 and 150 seconds is this is simply to much.
> 
> What can I do to solve this problem ?

Are you having bayes data on a file-based database?
This is a certain performance killer with large databases,
even more with auto-expiry enabled.

Switch bayes to SQL. See README and schemas in
the sql/ subdirectory of the SpamAssassin package.
If using MySQL, use the Mail::SpamAssassin::BayesStore::MySQL
as a bayes_store_module, along with an InnoDB engine!

  Mark

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot 
org

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot 
org

Reply via email to