[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: restricting process limit

On Mon, 26 Apr 2004, George Georgalis wrote:
> On Mon, Apr 26, 2004 at 06:44:35PM +0200, LeVA wrote:
>>I have a 'spam' user, and I've set up postfix, to run a tiny little
>>script as this 'spam' user. This script accepts messages thru the
>>stdin, and it filters the message thru the spamd daemon with the spamc
>>client. After the filtering, it sends the message using the 'sendmail'
>>(postfix's sendmail) program.
>>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.

> So, I think your fix will be to limit the max incoming concurrency on
> postfix, since that is really your problem. (can't help with details
> as I don't run postfix.) With a lower incoming concurrency, mail will
> stay queued on remote servers until they try again any your local box
> is not too busy.

Two things will help here:

Calling spamc directly, without using a shell script, will reduce the
overheads dramatically and make life a bit nicer for you.  Stick this in
to master.cf as your spam path:

# My local content filtering, done with SpamAssassin.
spam	  unix	-	n	n	-	-	pipe
  flags=Rq user=mailfilter argv=/usr/bin/spamc -x -u ${user} -e /usr/sbin/sendmail -f ${sender} -- ${mailbox}@localhost

Then add to main.cf the following:

spam_destination_recipient_limit = 1
spam_destination_concurrency_limit = 5

The recipient limit is needed if you directly call spamc as above,
without the shell in between.

The concurrency limit is the one that controls how many spamc instances
there can be at once.

If you ever reach total enlightenment while you're drinking a beer,
I bet it makes beer shoot out your nose.
        -- Jack Handy

Reply to: