spamd/spamc are your friends. When I started using spamassassin on my laptop I got the same problem each time I plug it on the network. My conclusion was that spamassassin was the real problem (with the forked perl interpretor for each mail). Worst than you, it triggered the bug in current 2.4 kernel who deadlocks under heavy load for unexpected reason. I simply replaced 'spamassassin -P' in my procmail config by spamc and added spamd in init.d. I also change a config of spamc to deliver the mail directly if it can not reach spamd (safer). Now I know when mail arrives (it takes cpu and wakes up my disk) but it is acceptable. Christophe On Thu, Feb 21, 2002 at 02:46:24PM -0800, Karsten M. Self wrote: > I've been running spamassassin on several boxes (home and work) over the > past few weeks. It rocks. Completely replaced my own procmail spam > detection recipies. > > The problem I'm having as a dialup user is when I pull mail > periodically. With several hundred emails stacked up, I can readily run > into user process limits (256 processes per user) while handling mail. > > My system uses: > > - fetchmail (run daemonized from /etc/fetchmailrc on one system, run > manually on another) to pull mail from a POPD server. > > - exim for local delivery. > > - procmail for filtering > > - spamassassin, as part of the procmail filters > > - ricochet, a reporting script, for reporting highly-rated spam > automatically. > > My typical process load is ~120-130 processes, single user, on the box. > > When pulling mail, I'll see the system spike to 350 or more processes. > It appears that each mail delivery initiates a separate exim process > (which I hadn't expected) and procmail process (this I had). > > Looking through references, it appears I can recompile my kernel to > increase user limits (defaults appear to be 512 processes, max 256 per > user, which seems low these days). I believe threaded apps (e.g.: > Java) run into similar issues. > > I'd also think I should be able to tweak my configurations with > fetchmail and/or exim such that fewer processes are spawned, or they are > spread out over a longer time (with a lower peak process load). > > Wondering who else is seeing similar issues and how they're tackling > them. > > Peace. > > -- > Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ > What part of "Gestalt" don't you understand? There is no K5 cabal > http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org > -- Christophe Barbé <christophe.barbe@ufies.org> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Imagination is more important than knowledge. Albert Einstein, On Science
Attachment:
pgp09B474FEd3.pgp
Description: PGP signature