Re: restricting process limit
On Wed, Apr 28, 2004 at 03:18:57AM -0400, George Georgalis wrote:
> On Wed, Apr 28, 2004 at 02:59:12PM +1000, Daniel Pittman wrote:
> >On Tue, 27 Apr 2004, Dan Christensen wrote:
> >> Daniel Pittman <daniel@rimspace.net> writes:
> >>> On Mon, 26 Apr 2004, George Georgalis wrote:
> >>>> On Mon, Apr 26, 2004 at 06:44:35PM +0200, LeVA wrote:
> >>>>>So when I'm getting a large amount of messages there is approx.
> >>>>>15-20 spamc/spamd running. I want to limit this to ~5.
> >>>> I suspect if spamc invokes spamd but spamd reached its max-children
> >>>> then spamc will act as if spamd timed out, or report ham.
> >>> That depends on the options you pass to spamc; I pass -x which says
> >>> "report a temp failure in that case", and advise that for general
> >>> use.
> >> I'm not sure if this is helpful to the original poster, but I invoke
> >> spamc from within procmail, and use a lockfile to limit it to one
> >> invocation at a time.
> >> Does anyone see a problem with this setup? (I use exim as my MTA.)
> >No, no problem. This is a pretty high overhead solution, though, and
> >the original question was about limiting that overhead. :)
> yep. SA is high overhead. the annoying thing is that besides all the
>
> SA seems the only real choice for an OSS spam filter, but I find the
> api, poor, and looking at the code tells me resource efficiency was never
> a consideration either.
>
> I'm wanting to write a program that process mail through SA modules,
> but more efficiently. I'm surprised I've not found one out there already.
> Maybe scrubber is the answer? http://projects.gasperino.org/scrubber/
> (don't know yet...)
I've had good success with MailScanner which uses SpamAssassin as a perl
library. It does not use spamc or spamd. If I understand correctly this
approach has far less overhead than the procmail/spamc/spamd approach.
http://mailscanner.info
-Eric Rz.
Reply to: