On Mon, 2010-09-06 at 17:32 -0500, Chris wrote:
> On Mon, 2010-09-06 at 17:03 +0200, Karsten Bräckelmann wrote:
> > Unless the limit of 50k results in quite some spam ending up unprocessed
> > by SA, I doubt this will help.
> >
> > Dropping large-ish third-party rule sets, if any, is much more likely to
> > make a noticeable difference. SA, as well as ClamAV. If memory serves me
> > right, you are using ClamAV third-party signatures -- some of which have
> > been reported to hog memory galore.
> > Since you mentioned procmail, your spamc calling recipe is *with*
> > locking, right? Limiting concurrent SA processes pretty much to one as
> > far as filtering is concerned. (As Bernd and previously others in this
> > thread have pointed out, limit the concurrency.)
>
> I believe I have this right Karsten
>
> :0 fw : $ASSASSINLOCK
Indeed, you do. Well, if $ASSASSINLOCK evaluates to something, always
evaluates to the same, and actually is writable. ;)
> * < 150000
> | /usr/local/bin/spamc -f
>
> I've trimmed my third party rule sets down to the sought rules and
> disabled unnecessary rule sets I had setup in my local.cf
Good one, particular if constrained with that "unnecessary". That part
of my previous post strongly aimed at ClamAV third-party sigs, though.
(Ah, well, and not loading them twice. But I believe we got that
settled. ;)
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
