leva

Hi!

I'm using spamassassin on my system (Pentium-MMX 233 w/ 160Mb RAM), and
it works fine, if I get small amount of messages. But when I get a lot
of messages, the ultra-fast 233MHz processor can not take it, and it
gets very slooow.
My setup looks like this:

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. How can I do this. The
spam user's passwd entry looks like this:

spam:x:2528:2528:spamd:/no/where:/no/shell

It has no shell, so I can not use the ulimit function in bash. But what
else could I do?

Thanks a lot!

Daniel

--
LeVA


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

thomas schuering

Hi,


/usr/sbin/spamd -d -m 5

'-d' : daemonize
'-m 5' : Allow maximum 5 children

Just checkout: man spamd


Regards, Thomas
--
"Der Horizont vieler Menschen ist ein Kreis mit Radius Null -
und das nennen sie ihren Standpunkt." - A. Einstein


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

noah meyerhans

First of all, this is OT for debian-security. It should have gone to
debian-user. Second, RTFM. From spamd(1):

-m number, --max-children=number
Specify a maximum number of children to spawn. Spamd
will wait until another child finishes before forking
again. Meanwhile, incoming connections will be queued.

Please note that there is a OS specific maximum of
connections that can be queued (Try "perl -MSocket
-e'print SOMAXCONN'" to find this maximum). Also, this
option causes spamd to create an extra pipe for each
child.

noah


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAjUOBYrVLjBFATsMRAkXZAJ9Q8SleQf1rOjgzwnM+8j cfEeQfDwCfYnf/
SP1tXvIsXLHBr46G6+ht2J4=
=dNF/
-----END PGP SIGNATURE-----

george georgalis

I suspect if spamc invokes spamd but spamd reached its max-children then
spamc will act as if spamd timed out, or report ham.

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.

Regards,
// George

--
George Georgalis, Architect and administrator, Linux services. IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org
Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

daniel pittman

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.


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.

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


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

emmanuel lacour

I would suggest having a look at amavisd-new for running SA. I saw a big
performance gain when switching from spamc+spamd to amavisd-new + SA

deb http://www.backports.org/debian/ woody amavisd-new

--
Emmanuel Lacour ------------------------------------ Easter-eggs
44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 41 35 00 76
mailto:elacour@easter-eggs.com - http://www.easter-eggs.com


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

daniel pittman

I made this move recently myself, and can say that I didn't see a
significant change in performance between amavisd-new and the "directly
invoke spamc/sendmail" configuration that I posted.

It seems to me that the shell interpreter and script overhead is a huge
part of the cost of processing spam with Postfix using the simple filter
model.

Daniel


--
Now that mountains of meaningless words and oceans divide us
And we each have our own set of stars to comfort and guide us
-- Nick Cave, _Come Into My Sleep_


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

dan christensen

Daniel Pittman <daniel@rimspace.net> writes:

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.)

Thanks,

Dan


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

daniel pittman

No, no problem. This is a pretty high overhead solution, though, and
the original question was about limiting that overhead.

Daniel

--
99 dreams I have had / In every one a red balloon
It's all over and I'm standing pretty / In this dust that was a city
If I could find a souvenir / Just to prove the world was here
-- Nina, _99 Red Balloons_


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

george georgalis

yep. SA is high overhead. the annoying thing is that besides all the
regex work that needs being done, SA is very inefficient in the process.

one very annoying observation is the load that persists after the tests
complete. Find a slow host, put lots of SA modules on it and watch your
spamd log and top, as you check a message... after the score is logged
and the message is processed, spamd instances continue using a lot of
resources, sometimes much longer than the time taken to process the
message.

Figuring out what this "post process" resource load is or even which
modules cause how much processing load, has been, well, not easy.

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...)

Back to my own scripts, I'm having a real hard time so much as finding
doc (vs example) of the module format. Any tips on what I'm missing
are more than welcome.

thanks-
// George


--
George Georgalis, Architect and administrator, Linux services. IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org
Key fingerprint = 5415 2738 61CF 6AE1 E9A7 9EF0 0186 503B 9831 1631


--
To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org