On Tue, May 24, 2005 at 02:50:46PM +0100, Ben Wylie wrote: > debug: bayes: expiry check keep size, 0.75 * max: 375000 > debug: bayes: token count: 498176, final goal reduction size: 123176 > debug: bayes: First pass? Current: 1116929366, Last: 1116896823, atime: > 5529600, count: 5721, newdelta: 256826, ratio: 21.5305016605489, period: > 43200 > debug: bayes: Can't use estimation method for expiry, something fishy, > calculating optimal atime delta (first pass) > debug: bayes: expiry max exponent: 9 > debug: bayes: atime token reduction > debug: bayes: ======== =============== > debug: bayes: 43200 486091 > debug: bayes: 86400 475937 > debug: bayes: 172800 462174 > debug: bayes: 345600 437604 > debug: bayes: 691200 393656 > debug: bayes: 1382400 330824 > debug: bayes: 2764800 191807 > debug: bayes: 5529600 1729 > debug: bayes: 11059200 0 > debug: bayes: 22118400 0 > debug: bayes: First pass decided on 5529600 for atime delta > > What exactly is it doing at this stage? Why does it take so long, and is > there a way to reduce the time it takes to do this?
This is all explained in the sa-learn documentation. Basically, the first pass (above) tries to figure out at what age tokens should be trimmed from your DB. It tries to estimate, but if the previous expiry and the current expiry are too different, it'll have to calculate out by going through every token and coming up with the atime difference. > Again on my slow system it then takes a further 10 minutes to carry out > expiration. SA has to go through all the tokens, copying to a new DB all the ones that are to be kept. > There's probably little i can do to speed this part up. If you went to a SQL backend, expiry is faster in general. Otherwise, keep less tokens in your DB. You set it to 375000 instead of the usual 150000. If you did so, the above expiry would have used: debug: bayes: 1382400 330824 which would make the next round much faster. > Now looking at a log of a message being scanned, it seems to check all > relays to see which ones are trusted. Yup. > Is there any reason for it to continue to carry out these checks if all > trusted score set to 0 in my local.cf file? Absolutely, that's how SA figures out which relays to test via RBL, etc. The ALL_TRUSTED rule just uses that information, but (un)trusted_relays are always calculated. > However SA continues to check all rules before returning the result. Is it > possible to get it to stop tests once a specific score has been reached? No. > If this is possible, then is it possible to change the order in which SA > carries out the tests so i can put the uribl tests at the beginning, and > avoid having to carry out all of the others if all the uribl tests hit? It is possible to change the order (RTM), but there is no short-circuit ability anymore/yet. -- Randomly Generated Tagline: "If you're running the latest version of IIS, then you're not vulnerable to this [security hole], but you're vulnerable to something new." - Phil Cox
pgpV05HOvIbIl.pgp
Description: PGP signature
