* Justin Mason ([EMAIL PROTECTED]) wrote: > > I get on an average 350 open procmail processes at any one time. 'ps ax > > |grep proc | wc -l" > > I need to figure out how to scale this. The machine is a PIII with 512 > > megs in Raid 5 configuration.
Ugh. Just a thought, but a more effecient system may be to write a small daemon for sendmail to deliver to, which communicates directly to spamd (which you might like to spread across a few different machines if you find the one system getting bogged down), and then delivers the filtered message. You could spread spamd to other machines and stick to procmail, but you're still going to end up with hundreds of copies of procmail sitting around waiting for something to happen. Or you could have sendmail do delivery itself; have it filter through spamc before delivering. I have no idea how sendmail will cope with the filter taking a long time (I'm an exim bod, anyway), but it may well be worth looking at. Or do the filtering higher up the mail hierachy; maybe run the filters on a bunch of outside-facing boxes with a round-robin MX setup and have all those boxes deliver to your main system which then doesn't have to wait for every mail to filter. > Basically a spam-check may take up to 10 seconds per mail, so sendmail > should run only a certain number of concurrent deliveries (20 or so?) > and wait for them to complete before spawning more. Isn't that going to result in a nasty backlog of deliveries? -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - Best of all is never to have been born. Second best is to die soon. _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
