You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by poifgh <ab...@gmail.com> on 2009/07/31 08:55:21 UTC
Parallelizing Spam Assassin
Hi
I was measuring how quickly could SA [spam assassin] process spams when
several SA processes are run in parallel over separate mbox files. I used a
8 core machine. Below are the numbers when I forked different number of
processes.
Fork = 8;
Rate = 57 msgs/sec
Fork = 4;
Rate = 44 msgs/sec
Fork = 1;
Rate = 22 msgs/sec
I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
a linear increase in the throughput? Is a file locking creating the
bottleneck? If yes, which particular file is being locked? If no, what could
be the reason for this?
thnx
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24751958.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Paweł Sasin <ha...@wp-sa.pl>.
> In my tests - there was not MTA. The mails/spam were collected from
> some server in mbox format and fed to SA using --mbox switch. The
> size of msgs was not altered in any fashion - just the usual size of
> incoming spam/mails
If you're interested in testing/tuning spamassassin for heavy loads you
should consider using spamd daemon. Then you may use SLAMD [1] as
performance evaluation platform [2].
It takes some effort to set up the environment, but SLAMD helps in
repetitive testing and keeping track of the results (comparison,
history, charts).
[1] http://www.slamd.com
[2] https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5689
--
Pawel Sasin
"WIRTUALNA POLSKA" Spolka Akcyjna z siedziba w Gdansku przy ul.
Traugutta 115 C, wpisana do Krajowego Rejestru Sadowego - Rejestru
Przedsiebiorcow prowadzonego przez Sad Rejonowy Gdansk - Polnoc w
Gdansku pod numerem KRS 0000068548, o kapitale zakladowym
67.980.024,00 zlotych oplaconym w calosci oraz Numerze Identyfikacji
Podatkowej 957-07-51-216.
Re: Parallelizing Spam Assassin
Posted by Nigel Frankcom <ni...@blue-canoe.com>.
OK - I can see what metrics you are trying to ascertain - I think. I'm
not sure that your test and real life are 'right'. For obvious reasons
I don't want to carry this one on via list - I would suggest you ask
Justin and I will be happy to give info on my local setup (this
assumes Justin can grab time away from toxic nappies/daipers)
There is a lot you can do to ameliorate load. On bad days my quad does
50 a second so it's doable. I will freely admit I have no clue quite
how this came to be, but it is (a case of having colleagues knowing
more than I do - for which I am eternally grateful; the usual culprits
know who they are)
Kind regards
Nigel
On Fri, 31 Jul 2009 11:41:14 -0700 (PDT), poifgh
<ab...@gmail.com> wrote:
>
>In my tests - there was not MTA. The mails/spam were collected from some
>server in mbox format and fed to SA using --mbox switch. The size of msgs
>was not altered in any fashion - just the usual size of incoming spam/mails
>
>There are no AV [you mean Anti Virus right?] running on the machine
>
>Would be back with results
>
>--
>
>
>
>
>Nigel Frankcom-2 wrote:
>>
>> I'm assuming you run a tad more messages than I, but on a quad with a
>> failover I have never seen the failover kick in 4 years. This is not
>> disputing your observations, just noting mine.
>>
>> I claim absolutely no knowledge about the core processing/stacking
>> though I would assume (perhaps incorrectly) that the parsing would be
>> part of the software (MTA).
>>
>> I freely admit I only picked up what seems the tail end of this thread
>> but having used SA for so many years I think I have at least a handle
>> on how it plays (hence the failover). My failover SA is in place to
>> handle slow queries from the primary SA. Assuming (again) that mail
>> size has been factored and any AV is running remotely?
>>
>> Just a few thoughts based on a very cursory read of a few posts, sadly
>> - or happily, work make my contributions here limited.
>>
>> I'd be interested in the results of this though.
>>
>> Kind regards
>>
>> Nigel
>>
>> PS - apologies if I'm repeating prior observations.
>>
>> On Fri, 31 Jul 2009 10:41:47 -0700 (PDT), poifgh
>> <ab...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>>Henrik K wrote:
>>>>
>>>> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
>>>> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
>>>> used
>>>> and any nondefault rules/settings? Certainly sounds strange that 1 core
>>>> could top out the same. Anyone else have figures? Maybe I've borked
>>>> something myself..
>>>>
>>>
>>>The problem is not with 22 being a low number, but when we have other free
>>>cores to run different SA parallely why doesnt the throughput scale
>linearly
>>>.. I expect for 8 cores with 8 SA running simultaneously the number to be
>>>150+ msgs/sec but it is 1/3rd at 50 msgs/sec
>>
>>
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
In my tests - there was not MTA. The mails/spam were collected from some
server in mbox format and fed to SA using --mbox switch. The size of msgs
was not altered in any fashion - just the usual size of incoming spam/mails
There are no AV [you mean Anti Virus right?] running on the machine
Would be back with results
--
Nigel Frankcom-2 wrote:
>
> I'm assuming you run a tad more messages than I, but on a quad with a
> failover I have never seen the failover kick in 4 years. This is not
> disputing your observations, just noting mine.
>
> I claim absolutely no knowledge about the core processing/stacking
> though I would assume (perhaps incorrectly) that the parsing would be
> part of the software (MTA).
>
> I freely admit I only picked up what seems the tail end of this thread
> but having used SA for so many years I think I have at least a handle
> on how it plays (hence the failover). My failover SA is in place to
> handle slow queries from the primary SA. Assuming (again) that mail
> size has been factored and any AV is running remotely?
>
> Just a few thoughts based on a very cursory read of a few posts, sadly
> - or happily, work make my contributions here limited.
>
> I'd be interested in the results of this though.
>
> Kind regards
>
> Nigel
>
> PS - apologies if I'm repeating prior observations.
>
> On Fri, 31 Jul 2009 10:41:47 -0700 (PDT), poifgh
> <ab...@gmail.com> wrote:
>
>>
>>
>>
>>Henrik K wrote:
>>>
>>> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
>>> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
>>> used
>>> and any nondefault rules/settings? Certainly sounds strange that 1 core
>>> could top out the same. Anyone else have figures? Maybe I've borked
>>> something myself..
>>>
>>
>>The problem is not with 22 being a low number, but when we have other free
>>cores to run different SA parallely why doesnt the throughput scale
linearly
>>.. I expect for 8 cores with 8 SA running simultaneously the number to be
>>150+ msgs/sec but it is 1/3rd at 50 msgs/sec
>
>
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24761236.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Nigel Frankcom <ni...@blue-canoe.com>.
I'm assuming you run a tad more messages than I, but on a quad with a
failover I have never seen the failover kick in 4 years. This is not
disputing your observations, just noting mine.
I claim absolutely no knowledge about the core processing/stacking
though I would assume (perhaps incorrectly) that the parsing would be
part of the software (MTA).
I freely admit I only picked up what seems the tail end of this thread
but having used SA for so many years I think I have at least a handle
on how it plays (hence the failover). My failover SA is in place to
handle slow queries from the primary SA. Assuming (again) that mail
size has been factored and any AV is running remotely?
Just a few thoughts based on a very cursory read of a few posts, sadly
- or happily, work make my contributions here limited.
I'd be interested in the results of this though.
Kind regards
Nigel
PS - apologies if I'm repeating prior observations.
On Fri, 31 Jul 2009 10:41:47 -0700 (PDT), poifgh
<ab...@gmail.com> wrote:
>
>
>
>Henrik K wrote:
>>
>> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
>> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
>> used
>> and any nondefault rules/settings? Certainly sounds strange that 1 core
>> could top out the same. Anyone else have figures? Maybe I've borked
>> something myself..
>>
>
>The problem is not with 22 being a low number, but when we have other free
>cores to run different SA parallely why doesnt the throughput scale linearly
>.. I expect for 8 cores with 8 SA running simultaneously the number to be
>150+ msgs/sec but it is 1/3rd at 50 msgs/sec
Re: Parallelizing Spam Assassin
Posted by Justin Mason <jm...@jmason.org>.
On Sat, Aug 1, 2009 at 10:04, Henrik K<he...@hege.li> wrote:
>
> On Sat, Aug 01, 2009 at 12:04:08AM -0700, Linda Walsh wrote:
>> Well -- it's not just the cores -- what was the usage of the cores that
>> were being used? were 3 out the 8 'pegged'? Are these 'real' cores, or
>> HT cores? In the Core2 and P4 archs, HT's actually slowed down a good
>> many workloads unless they were tightly constructed to work on the same
>> data in cache. Else, those HT's did just enough extra work to block cache
>> contents more than anything else.
>
> I really doubt there's HT involved in a recent looking 8 core 16GB machine..
>
>> What's the disk I/O look like? I mean don't just focus on idle cores --
>> if the wait is on disk, maybe the cores can't get the data fast enough.
>
> As we already guessed, AWL (BerkeleyDB) caused disk I/O and slowness. For
> heavy loads you need to use SQL (or maybe the better BDB plugin in 3.3 if we
> get it working).
>
>> If the network is involved, well, that's a drag on any message checking.
>> I'm seeing times of .3msgs/sec, but I think that's with networking turned
>> on. Pretty Ugly.
>
> It affects single messages, but not total throughput. With network checks
> you just dedicate a lot more childs. Waiting for network responses takes no
> CPU time, thus you can process more messages simultaneously.
although you will also need to allocate more memory, as well, to
ensure that no swapping takes place.
--
--j.
Re: OT: Nehelam's New HT ability....
Posted by Linda Walsh <sa...@tlinx.org>.
Per Jessen wrote:
> But how about the core subject here - the hyperthreading? Have you
> noticed anything very different wrt that? I haven't, but it will
> certainly depend on your workload.
----
Definitely will depend on workload. But I noticed more power
consumption and it seemed to handle more real work in the new
HT's, but I haven't had the sys long enough to do alot of benching.
Major noticeable diff in sys load and fan's kicking in in running
4 cpu intensive processes vs. 8 (used multiple copies of
sh-keygen -b 16384) to keep it busy - 8192 finished too quickly..~10-15 secs).
Sigh....
Re: OT: Nehelam's New HT ability....
Posted by Nix <ni...@esperi.org.uk>.
On 8 Aug 2009, Per Jessen told this:
> Nix wrote:
>> On 1 Aug 2009, Linda Walsh stated:
>>
>>> Per Jessen wrote:
>>>> Not sure about that - AFAICT, it's exactly the same technology. (I
>>>> haven't done in exhaustive tests though).
>>>
>>> Supposedly 'Very' different (I hope)...
>> Oh yes. I have a P4 here (2GHz Northwood), and two Nehalems (one 2.6GHz
>> Core i7 with 12Gb RAM and a 2.26GHz L5520 with 24Gb, hello overkill).
>> Compared to the P4s, the Nehalems are *searingly* fast: the performance
>> difference is far higher than I was expecting, and much higher than the
>> clockspeed different would imply.
>
> But how about the core subject here - the hyperthreading? Have you noticed anything very different wrt that? I haven't, but it will
> certainly depend on your workload.
Yes. My primary benchmark was a parallel profiledbootstrap of GCC 4.4
sans Java ('cos that requires lots of other infrastructure I didn't have
present at the time): this tests parallel cache-bashing CPU-bashing
stuff, and also tests out the disk subsystem hard because every
compilation launched during stage 3 writes out several dozen megabytes
of profiling state.
Without hyperthreading, 'make -j 6' was the fastest available option,
taking 1392s to do a full bootstrap: turn turbo mode off and that rises
to 1491s. With hyperthreading, 'make -j 11' was fastest, and took 1094s
without turbo mode, 982s with it. Again, not an earthshaking speedup,
but worth it.
By comparison, that P4? It takes *five hours* to do the same job.
982s versus perhaps 18000s... nearly twenty times faster.
Re: OT: Nehelam's New HT ability....
Posted by Per Jessen <pe...@computer.org>.
Nix wrote:
> On 1 Aug 2009, Linda Walsh stated:
>
>>
>> Per Jessen wrote:
>>> Not sure about that - AFAICT, it's exactly the same technology. (I
>>> haven't done in exhaustive tests though).
>> ----
>>
>> Supposedly 'Very' different (I hope)...
>
> Oh yes. I have a P4 here (2GHz Northwood), and two Nehalems (one 2.6GHz
> Core i7 with 12Gb RAM and a 2.26GHz L5520 with 24Gb, hello overkill).
> Compared to the P4s, the Nehalems are *searingly* fast: the performance
> difference is far higher than I was expecting, and much higher than the
> clockspeed different would imply.
But how about the core subject here - the hyperthreading? Have you
noticed anything very different wrt that? I haven't, but it will
certainly depend on your workload.
/Per
Re: HT-perf, paralism, thruput+latncy (dsk, net, RBLs) powr usg/meas, perlMiltring & ISP's reducng spamd latency
Posted by Linda Walsh <sa...@tlinx.org>.
Nix wrote:
> [This is really OT for spamassassin, isn't it? Should we take it
> off-list?]
--
a bit -- and somewhat not. Much of it boils down to speed. How to best do
it, parallelism, new hardware features...lowering latency...etc.
I'd really hoped to speed up my SA processing -- at least it can handle
a sizable concurrent load now, that's an improvement. Need to figure out
a way to cache or speedup the network requests -- I'm sure it's mostly
latency on the spamd servers i'm checking w/. The highest my download speed
went was about 500K (on a 768K DSL)...it's all in packet latency that's the
prob.
> On 8 Aug 2009, Linda Walsh spake thusly:
> OK, you've out-RAIDed me.
----
It's a server. Mostly unraided...sorta...4 of them are in 2 VD's in
mirror mode. the system disk is a 15K SAS, but only 70G space. The rest
are what RAID are supposed to be -- Redundant Arrays of _Inexpensive_ disks
(SATA). Boy was Dell pissed. They really don't like selling bare-bones
systems. I had to buy the disk trays elsewhere (dell won't sell them
separate from a disk). Only 1 VD is a real RAID(5) with a whopping
3 disks...ooOOOOooo.. 2 disks are sitting around as spares until I can
figure out how to add them to existing arrays (supposed to be 'easy' and
the controller rebuilds -- but nooOOOOooooo....I'm just spending too much
time on computer solving mail-filter problems while forcing myself
uptospeed w/perl5.10's new features, CSS, and fonts again (I just hosed my
desktop's fonts, so need to reboot...oops).
>> I'd also prefer the my own *choice* of whether or not to use the on-disk
>> cache ... Maybe some of this control will get into the or does the bios
>> have to support everything?
>
> Well, you'll never get the option to turn off the Linux kernel's disk
> cache,
---
On-disk cache = cache 16-32MB of cache on the disk. It really speeds
up writes when you are writing small junks as it can coalesce the writes to
physical positions on disk -- while the kernel only uses a generic 'model'
all disks. The real internal geometry is completely hidden these days --
you can see it talked about on Tom's HW occasionally when they bench
a disk. You see fast constant speeds at track 0 (outside of disk), then
you see multiple 'drops' as the sectors/track shrink due to lower diameter.
But the on disk cache -- all the kernel developers dis it because they run
unstable kernels that can leave up to 32MB in a write buffer on a disk if
it gets reset or loses power before it finishes flushing it's cache. But
on a system on a UPS, not running test-kernels all the time, unplanned
shutdowns are rare, so the speed-up is worth it. Just like the RAID
controller itself has it's own battery backed up (non-extensible) RAM (it
doesn't know about UPS's and such -- my previous server lasted 9 years...I
feel in large part due to it being on a power-conditioned UPS (APC SmartUPS
that supposedly puts out a sinewave, despite my flakey PG&E power).
> fast speeds -- then because executables and shared libraries run out of
> it,
---
I'm more worried about large write speeds. There, circumventing the
system cache and using direct i/o can get you faster throughput when doing
disk-to-disk copies -- the limiting factor is the target disk write rate,
and no kernel cache will help. What does help is overlapping reads from
one device and doing writes to the other device that fit in it's buffer.
Then you can theoretically get _closer_, but not quite, double the
throughput (as writes are slower). But if you write in, say 24M chunks to
a 34MB on-disk (no RAID) buffer, it can often get the data out while you
are reading the next 24MB from the 1st disk.
If you go through the kernel's system cache, it throws everything off
-- you can watch it -- the kernel will give priority to reads (as it
should, as reads usually block the CPU or the USER from getting things
done. While writes can *usually* be done lazy in the background. But on
D:D copies of large multi-gig files, you want write and read to be exactly
balanced for optimal throughput. But that's a *special* case, when you are
moving large data files around (for example a 157G full backup -- and
that's gzipped, because bzip2 (lzma is much worse, but way good at
compression) uses too much cpu. On my old server (which died after 9 years
(started with a P-II@400MHZ, ended with dual-P-III's at 1GHz, but 256K
cache each...hardly better than a celeron!) bzip2 would slow down backup
writing to disk to about 600K/s! gzip only cut speed by about half (from
20MB/s for raw data to 10MB/s). Compressed backups are nice, BUT, when you
need to access them -- if you need to unpack a 100+G level zero...ouch...
just to uncompress it would take hours!.
So ... while my new server is relatively fast -- I sorta earned it --
sitting on my old server giving feeding it power cycles through
a baby-bottle to keep it going at times...(had disk controllers updated,
all sorts of extra fans -- was never thermally designed for the CPU and
disk load i put on her. Oh well...
I'd be lucky if "spamc --learn" would process at 4-5 msgs/second!
>> Supposedly it has temp and electrical monitoring 'galore', but I can'
>> even read the DIMM temps.
>
> I can on mine! Actually I can read it two different ways, via IPMI and
> via the temperature sensors directly. They give completely different
> readings :/ I'm inlined to trust the sensors more than IPMI: half its
> figures seem to be completely fictional. (Also the IPMI engine often
> locks up and refuses to do anything until you power the whole machine off
> and unplug it from the wall. Not what you want in a robust monitoring
> system.)
---
Temp sensors directly? you mean manually on outside of box? Mine has
something like that too -- and I can read the cpu's but am not seeing the
DIMM's as I can with with older workstation (i5000k memory monitor).
>> I went with the 'eco' power supplies at 570W
> That's 'eco'?!
---
Compared to my workstations at 750 and 1KW, yeah!...This is a server we
are talking about, not a desktop. The graphics cards alone on PC's, these
days suck way big -- for the GTX 260 series, they recommend no less than
a 600W PW, and for the GTX 280/285 -- I think 750-1K is the norm.
> (vs. 870).
>
> That's not a power supply, that's an electric fire.
???
You obviously aren't running 224-core graphics cards. (That's the
low-end, revised GTX-260). Dunno about the the 285, I think the 280 was 256
or so cores...(and those are on top of any general CPU's you might have).
>> BTW, I'm running at 1333MHZ, so maybe it's a heat dissipation prob and
>> not power?
>
> Nah, that machine is hugely overequipped with cooling, and clocking it
> down to 1066 and slamming heat-inducing CPU-pounding stuff through it for
> 24 hours plus gives no problems whatsoever. I'm sure it got hotter in 24
> hours of CPU churning than it did in one twenty-minute(!) GCC bootstrap,
> but the latter, with faster RAM, MCEd on me more than once.
----
What PS do you have?
>> I'm only pulling 157-160 to a max of 260
> How can you tell without specialized power monitoring hardware?
---
Specialized? *cough*....they sell 'watt-minders'
(http://www.sierraenergyproducts.com/) for under $40 and 'kill-a-watts'
(http://www.amazon.com/P3-International-P4400-Electricity-Monitor/dp/B00009MDBU)
for under 30$ these days. Mine's an older model with more bells/whistles,
but the computer, itself, actually displays it's power consumption in
BTU/HR or Watts (trade-off between that and a constant temp display in C or
F) on the front panel. It's accurate according to my external 15 year old
meter... My external meter is more expensive, but was around before the
others and has more functions that most people don't need.
My external meter, a 'Brand Electronics'
(http://www.brandelectronics.com/) meter, is s pretty accurate -- down to
.1W, also logs total, computes cost/month (enter your elec cost), also
shows the iRMS/Power Factor, VA's, and VAR's). Bought it about 10 years or
more ago when I went on an energy kick and reduced my household elec by
2/3rds... (slowly edged up again, but still less than half of my heights
back in the mid 90's). . Their prices, like everything else have gone up
in the past 15 years.. The Model 21-1850/CI includes a computer interface
to dumps and examine the logging. It's got a lifetime warrantee and it has
lasted....
>> Oblig:sa-users -- I may finally have my 'dead -email' restart problem
>> solved.
> I had that too! Well, OK, my ISP broke my email entirely (by changing my
> static IP without warning, denying me access to my DNS to adjust it
> accordingly, and breaking the backup MX they provided so that it bounced
> all email to me with a relaying denied message).
----
Ouch -- at least my mail probs are *usually* recoverable. Only had one
time when I bounced email (unknowingly) for 3 days solid...Ouch!
I let my ISP (speakeasy.net) manage my email collection, and
I downloaded with imaps -- so if I go down , it backs up on their servers
for a while. My quota will hold about a week or so, of me being dead -- my
backup plan would be to forward my email to one of my gmail
accounts...they have 4GB each! :-)...then I can later imap download it from
them! Very Sweet!
> Google for 'zetnet breathe fiasco' for more than you could possibly want
> on the disaster. I got off lightly: other people have had no email or
> news for many months, and some people lost all their old email too (!)
>
>> I added the 'delay time' taken by spamd when running my email inputs
>> (its' actually my filter delay time, but the max diff between the two is
>> about .01 seconds, so it's mostly spamd delay -- my stats for today from
>> ~9:30am are: (n=#emails) n=4513, min=3.27s, max=208.09s, ave=35.16s,
>> mean=27.43s
----
I think spamd alone (w/no network tests, takes well under a second).
I need to look at what network tests are taking the most time and seeing
how much value they add -- that might speed up my per-message rate to best
effect.
Rewriting my mail filter script (it's evolved since before modern
alternatives like procmail were around (in fact I tried procmail, and had
it too unreliable (at the time v<1.0) for my needs. My initial version of
my script was written in Perl3.... Much of my recent pain with mail
backlog and spamd taking so much time has been tweaking the script for some
new addresses and realizing it was getting "too unweildy", again..and
needed a make-over...and there's all those new features in 5.10. Before
I knew it...insufficient testing before putting it in place and all my
email was getting backed up in various ways ... all sorts of new ways to
create messes. But through it all, I don't think I sent any bounce
messages (or lost any email)....at one point had over 1000 processes
'deadlocked', but was able to unwind them w/o losing email or generating
bounce messages.
I have fantasies about perl 5.12 or 5.14 getting fancy with some of
it's 'foreach(@array)' processing -- and allowing for parallel threads that
can run on multi-cpu's. If the graphics processors are getting to over 200
vector processors, and rumor is Intel is going that direction as well for
their onboard graphics - but with more powerful 'thread' like action.
Windows will really take off over Linux as it has much lower thread
overhead (higher process overhead), but because Linus decided linux would
not have light weight threads -- just pseudo threads that are really just
more processes, he's optimized process creation, but hurt thread creation.
This could bit linux if a move comes toward more Hyperthreads which
only work best with 'lightweight threads' -- threads that cheap to spawn
and intimately intertwined in doing the same task... -- like that
'foreach(@array) I was talking about -- can you imagine the overhead of the
current process spawn and how it would kill something simple like that?
But (and it may require really bit 'loops' in perl to overcome the thread
creation overhead, as it's interpreted).
But thinking of parallelism -- if the bottleneck really is the speed of
the RBL servers, maybe the solution would be a distributed RBL among
independent ISP's (not biggies like AT&T/MaBell/Comcrass), as they'd be too
likely to much it up...but if my ISP hosted an RBL cache, for example for
their own customers...that could really speed things up. Dunno if it is
practical or doable or not, but sure might help the problem.
Linda
Re: OT: Nehelam's New HT ability.... and ability to handle spamd high load (preheating cache?)
Posted by Nix <ni...@esperi.org.uk>.
[This is really OT for spamassassin, isn't it? Should we take it
off-list?]
On 8 Aug 2009, Linda Walsh spake thusly:
> That's w/8 hard disks inside (though not under load...just spinning).
OK, you've out-RAIDed me.
> Seems to be no way on my machine (Dell is so limiting sometimes), to
> turn off unused hard drives, or only spin them up when I want to use
> them -- Some are hot-spare or just unconfig'ed, yet they spinup.
The disk controller chip would need to make this decision, I suspect,
and non-laptop ones are unlikely to be able to.
> I'd also prefer the my own *choice* of whether or not to use the
> on-disk cache as well as the raid controller's cache. I virtually
> never have unplanned shutdowns -- (its on a UPS that will run for
> >1hour under its load).
>
> Maybe some of this control will get into the lk -- or does the bios have
> to support everything?
Well, you'll never get the option to turn off the Linux kernel's disk
cache, because executables and shared libraries run out of it, and dirty
pages sit in it before the disk gets to writing them out: but you can
tune the balance between cache pages and other pages a bit with
/proc/sys/vm/swappiness. Normally it is hugely beneficial to have a big
cache, even if you have a caching hardware RAID controller: not only
is it often a lot bigger than a hardware RAID controller, but it's at
the page level, not the block-device level. Also it's closer to the CPU
thus there's less protocol and bus overhead getting stuff out of it.
(Of course the hardware RAID controller speeds things up as well.)
> Supposedly it has temp and electrical monitoring 'galore', but I can'
> even read the DIMM temps.
I can on mine! Actually I can read it two different ways, via IPMI and
via the temperature sensors directly. They give completely different
readings :/ I'm inlined to trust the sensors more than IPMI: half its
figures seem to be completely fictional. (Also the IPMI engine often
locks up and refuses to do anything until you power the whole machine
off and unplug it from the wall. Not what you want in a robust
monitoring system.)
> I went with the 'eco' power supplies at
> 570W
That's 'eco'?!
> (vs. 870).
That's not a power supply, that's an electric fire.
> BTW, I'm running at 1333MHZ, so maybe it's a heat dissipation prob and not
> power?
Nah, that machine is hugely overequipped with cooling, and clocking it
down to 1066 and slamming heat-inducing CPU-pounding stuff through it
for 24 hours plus gives no problems whatsoever. I'm sure it got hotter
in 24 hours of CPU churning than it did in one twenty-minute(!) GCC
bootstrap, but the latter, with faster RAM, MCEd on me more than once.
> I'm only pulling 157-160 to a max of 260 (didn't have disks
How can you tell without specialized power monitoring hardware?
> Oblig:sa-users -- I may finally have my 'dead -email' restart problem
> solved.
I had that too! Well, OK, my ISP broke my email entirely (by changing my
static IP without warning, denying me access to my DNS to adjust it
accordingly, and breaking the backup MX they provided so that it
bounced all email to me with a relaying denied message).
Google for 'zetnet breathe fiasco' for more than you could possibly want
on the disaster. I got off lightly: other people have had no email or
news for many months, and some people lost all their old email too (!)
> I added the 'delay time' taken by spamd when running my email inputs (its' actually my filter delay time, but the max diff between the two is about .01 seconds, so it's mostly spamd delay -- my stats for today from ~9:30am
> are: (n=#emails)
> n=4513, min=3.27s, max=208.09s, ave=35.16s, mean=27.43s
>
> I suppose for RBL's, some of those results are cached in bind as well?
Surely.
Re: OT: Nehelam's New HT ability.... and ability to handle spamd high load (preheating cache?)
Posted by Linda Walsh <sa...@tlinx.org>.
My bios doesn't allow shutting off HT, but does allow turning off
2 or 3 cores (allowing dual or single) -- I'd rather see that type
of feature at runtime - allowing system load to decide whether to activate another core -- though the diff on my 2.6GHZ in power consumption
when from about 157 watts (according to its front panel), to over
260 when I loaded all 8 'virtual' cores (only 4 corex2HT's/core).
That's w/8 hard disks inside (though not under load...just spinning).
Seems to be no way on my machine (Dell is so limiting sometimes), to
turn off unused hard drives, or only spin them up when I want to use
them -- Some are hot-spare or just unconfig'ed, yet they spinup.
I'd also prefer the my own *choice* of whether or not to use the
on-disk cache as well as the raid controller's cache. I virtually never have unplanned shutdowns -- (its on a UPS that will run for >1hour under its load).
Maybe some of this control will get into the lk -- or does the bios have
to support everything?
Supposedly it has temp and electrical monitoring 'galore', but I can'
even read the DIMM temps. I went with the 'eco' power supplies at 570W (vs. 870). But got the dual power supply backup -- I think, from what I an measure, it splits the power usage between the supplies unless one goes out. That could mean I really have a 1140W available? Dunno. Not sure exactly
what 'spare' means -- if it limits total consumption to level of 1 supply even though it splits the load (power meter hooked to one and watched it go to half load when other was plugged in).
BTW, I'm running at 1333MHZ, so maybe it's a heat dissipation prob and not
power? I'm only pulling 157-160 to a max of 260 (didn't have disks
churning though -- was just running copies of ssh-keygen -b 16384 -- that seems to take it a little bit...8192 comes out in about 10 seconds though. :-).
Oblig:sa-users -- I may finally have my 'dead -email' restart problem solved. Before, if I had a large queue, I had to stop fetchmail, often -- download only 10-20 at a time so it's emails wouldn't overload my sendmail queue (it gets backed up on spamassassin). My minimum time for SA (w/network tests) is around 3seconds. But during heavy loads it can really go high -- and my machine can just run out of memory and process space.
(part of it is sendmail looking up hosts of received email and bind starting 'cold' (no cache). But started with 2700 emails, ... after # processes
got to about 900, I chickened a bit and paused the fetchmail until they dropped under 400 (note, 'load' never went over '2' the whole time, so it was mostly network wait time). But after the initial clear I had about 2200 emails left and just let it run. At that point, I could see it keeping up -- bind's cache was alot warmer now, so not as much network traffic.
I added the 'delay time' taken by spamd when running my email inputs (its' actually my filter delay time, but the max diff between the two is about .01 seconds, so it's mostly spamd delay -- my stats for today from ~9:30am
are: (n=#emails)
n=4513, min=3.27s, max=208.09s, ave=35.16s, mean=27.43s
I suppose for RBL's, some of those results are cached in bind as well?
I wonder if there's anyway to speed up priming the cache before downloading a bunch of emails (not that I'm off line for that long usually) -- but it's sorta too bad bind doesn't save it's DB on disk on a shutdown, and read it back in after a reboot -- and then expire if needed...
Nix wrote:
> On 1 Aug 2009, Linda Walsh stated:
>
>>
>> Per Jessen wrote:
>>> Not sure about that - AFAICT, it's exactly the same technology. (I
>>> haven't done in exhaustive tests though).
>> ----
>>
>> Supposedly 'Very' different (I hope)...
>
> Oh yes. I have a P4 here (2GHz Northwood), and two Nehalems (one 2.6GHz
> Core i7 with 12Gb RAM and a 2.26GHz L5520 with 24Gb, hello overkill).
> Compared to the P4s, the Nehalems are *searingly* fast: the performance
> difference is far higher than I was expecting, and much higher than the
> clockspeed different would imply.
>
> Things the P4 takes half an hour to do, the Nehalems often slam through
> in a minute or less (!), especially things like compilations that need a
> lot of cache. Surprisingly, even some non-parallelizable things (like
> going into a big newsgroup in Gnus) are hugely faster (22 minutes versus
> 39 seconds: it's a *really* big newsgroup).
>
> I suspect the cause is almost entirely the memory interface and cache.
> The Northwood has, what, 512Kb L2 cache? The Nehalem has 256Kb... but it
> has 8Mb of shared L3 cache, and an enormously faster memory interface
> (the FSB is dead, Intel has a decent competitor to HyperTransport at
> last).
>
> I was an AMD fan for years, but the Nehalem has won me back to Intel
> again.
>
>> 1) You can't turn it off in the BIOS
>
> This depends on the BIOS. Both of mine provide the option: I benched
> it and found a 40% speedup for the things I do leaving it on.
>
>> 2) claim of benefit from increased cache (FALSE), (have older 2x2 Dual
>> Core machine with 4MBxL2 Cache/Dual core.
>> If you only use 1 Core/CPU, that 4MB L2 cache/Core)
>
> It's true that the cache-per-core is the same, but the FSB slows things
> down a lot.
>
>> to use memory faster than 800MHz -- only Quad cores go up to Quick
>> Connect Speeds that will support fastest memory of 1333MHz (even if
>> you only have 1 CPU). So you are 'encouraged' to go with
>> Quad over
>
> One of my machines has 1333MHz RAM, but unless I clock it down to
> 1066MHz I get regular machine check exceptions and random coredumps. Our
> best guess is that the motherboard on that machine doesn't supply enough
> power when the RAM is fully populated.
>
>> The biggest cool thing about Nehelam is power savings -- they implemented
>> Celeron's power-step tech in a big way. Quiescent cores crank down their
>> clocks independently to about 60% of top speed and have efficient sleep
>> states (I think some cores can be halted, but not sure). Some of their
>> processors have a 'turbo mode', which will some small amount faster speed
>> than the speed on the chip label (does that mean the turbo chips are really
>> faster rated chips...you tell me),
>
> Nope, it's much cooler than that. The power management system on the Nehalem
> is quite nifty (it's got more transistors than a 486 on its own). One of the
> things it can do is track power consumption and estimate the heat dissipation
> of different parts of the CPU core over time. All turbo mode does is exploit
> this to briefly overclock bits of the CPU die which happen to be running
> cool right now, then downclock them again to stop the die exceeding its
> rated thermal dissipation figures.
>
> This does mean that if you have crappy cooling on your Nehalem, turn off
> turbo mode...
>
>> BUT if fewer cores are used -- say only
>> 2/4, the turbo boost can be a small amount greater (don't have access
>
> That's because it realises that less heat is being dissipated.
>
>> (don't know if any is published). If one was to go from their
>> marketing graphs (HAHAHAHAHA), Turbo for 4 cores is about 10 more, and
>> if only 2/4 cores are running, it's an additional 10%. So marketing
>> hype/reality, might mean 1-3% faster?
>
> My (admittedly crude) benchmarks ('run a GCC bootstrap out of /tmp under
> /usr/bin/time') show about 6% for heavily parallelizable stuff, 9% for
> serial (the same thing without 'make -j'). (So it's quite close to the
> marketing figures.)
Re: OT: Nehelam's New HT ability....
Posted by Nix <ni...@esperi.org.uk>.
On 1 Aug 2009, Linda Walsh stated:
>
>
> Per Jessen wrote:
>> Not sure about that - AFAICT, it's exactly the same technology. (I
>> haven't done in exhaustive tests though).
> ----
>
> Supposedly 'Very' different (I hope)...
Oh yes. I have a P4 here (2GHz Northwood), and two Nehalems (one 2.6GHz
Core i7 with 12Gb RAM and a 2.26GHz L5520 with 24Gb, hello overkill).
Compared to the P4s, the Nehalems are *searingly* fast: the performance
difference is far higher than I was expecting, and much higher than the
clockspeed different would imply.
Things the P4 takes half an hour to do, the Nehalems often slam through
in a minute or less (!), especially things like compilations that need a
lot of cache. Surprisingly, even some non-parallelizable things (like
going into a big newsgroup in Gnus) are hugely faster (22 minutes versus
39 seconds: it's a *really* big newsgroup).
I suspect the cause is almost entirely the memory interface and cache.
The Northwood has, what, 512Kb L2 cache? The Nehalem has 256Kb... but it
has 8Mb of shared L3 cache, and an enormously faster memory interface
(the FSB is dead, Intel has a decent competitor to HyperTransport at
last).
I was an AMD fan for years, but the Nehalem has won me back to Intel
again.
> 1) You can't turn it off in the BIOS
This depends on the BIOS. Both of mine provide the option: I benched
it and found a 40% speedup for the things I do leaving it on.
> 2) claim of benefit from increased cache (FALSE), (have older 2x2 Dual
> Core machine with 4MBxL2 Cache/Dual core.
> If you only use 1 Core/CPU, that 4MB L2 cache/Core)
It's true that the cache-per-core is the same, but the FSB slows things
down a lot.
> to use memory faster than 800MHz -- only Quad cores go up to Quick
> Connect Speeds that will support fastest memory of 1333MHz (even if
> you only have 1 CPU). So you are 'encouraged' to go with
> Quad over
One of my machines has 1333MHz RAM, but unless I clock it down to
1066MHz I get regular machine check exceptions and random coredumps. Our
best guess is that the motherboard on that machine doesn't supply enough
power when the RAM is fully populated.
> The biggest cool thing about Nehelam is power savings -- they implemented
> Celeron's power-step tech in a big way. Quiescent cores crank down their
> clocks independently to about 60% of top speed and have efficient sleep
> states (I think some cores can be halted, but not sure). Some of their
> processors have a 'turbo mode', which will some small amount faster speed
> than the speed on the chip label (does that mean the turbo chips are really
> faster rated chips...you tell me),
Nope, it's much cooler than that. The power management system on the Nehalem
is quite nifty (it's got more transistors than a 486 on its own). One of the
things it can do is track power consumption and estimate the heat dissipation
of different parts of the CPU core over time. All turbo mode does is exploit
this to briefly overclock bits of the CPU die which happen to be running
cool right now, then downclock them again to stop the die exceeding its
rated thermal dissipation figures.
This does mean that if you have crappy cooling on your Nehalem, turn off
turbo mode...
> BUT if fewer cores are used -- say only
> 2/4, the turbo boost can be a small amount greater (don't have access
That's because it realises that less heat is being dissipated.
> (don't know if any is published). If one was to go from their
> marketing graphs (HAHAHAHAHA), Turbo for 4 cores is about 10 more, and
> if only 2/4 cores are running, it's an additional 10%. So marketing
> hype/reality, might mean 1-3% faster?
My (admittedly crude) benchmarks ('run a GCC bootstrap out of /tmp under
/usr/bin/time') show about 6% for heavily parallelizable stuff, 9% for
serial (the same thing without 'make -j'). (So it's quite close to the
marketing figures.)
Re: OT: Nehelam's New HT ability....
Posted by Linda Walsh <sa...@tlinx.org>.
Per Jessen wrote:
> Not sure about that - AFAICT, it's exactly the same technology. (I
> haven't done in exhaustive tests though).
----
Supposedly 'Very' different (I hope)...
1) You can't turn it off in the BIOS
2) claim of benefit from increased cache (FALSE),
(have older 2x2 Dual Core machine with 4MBxL2 Cache/Dual core.
If you only use 1 Core/CPU, that 4MB L2 cache/Core)
New machine with 1 Quad core (Dual core CPU's are too slow
to use memory faster than 800MHz -- only Quad cores go up to Quick
Connect Speeds that will support fastest memory of 1333MHz (even if
you only have 1 CPU). So you are 'encouraged' to go with Quad over
2x2Dual. Quad has 8MB L3 Cache, w/256K dedicated L2/Core. So
with HT 128K/thread. To get 2 Cores, they'll get 256K-L2 ea, +
8MB L3 shared. So about 3.125%more memory! WOW ea!...(though the
bandwidth for the fast core processors to main memory can be 2x faster).
3) Here's possible benefit: they've added more parallel resources to
each core -- so each thread can possibly get more done than the
old threads -- but this is only a maybe depending on workload.
The biggest cool thing about Nehelam is power savings -- they implemented
Celeron's power-step tech in a big way. Quiescent cores crank down their
clocks independently to about 60% of top speed and have efficient sleep
states (I think some cores can be halted, but not sure). Some of their
processors have a 'turbo mode', which will some small amount faster speed
than the speed on the chip label (does that mean the turbo chips are really
faster rated chips...you tell me), BUT if fewer cores are used -- say only
2/4, the turbo boost can be a small amount greater (don't have access
(don't know if any is published). If one was to go from their marketing
graphs (HAHAHAHAHA), Turbo for 4 cores is about 10 more, and if only 2/4
cores are running, it's an additional 10%. So marketing hype/reality,
might mean 1-3% faster?
I will say this much -- @ idle, w/8 disks (it's a server, so built-in GPU
with 8MB shared memory, if you aren't going headless) -- with dual/redundant
PS, it uses 157W. (1-PS, slightly more efficient at 146W). Major power
savings with possible big increases in speed. But you can't turn off HT
as in previous machines (at least not in the one I've had access to).
That power consumption is less than half their older Workstation model (though an idle graphics card still sucks quite a bit of useless ergs
(stupid Nvidia)..
Oblig SA content: When I ran 100 msgs through my filters (that connect to
spamd, but that uses net), the MHz immediately jumped from ~1596 up to 2300 on each of the '8' HT cores...so might be perfect for a server that gets sporadic loads! ;-)
-linda
Re: Parallelizing Spam Assassin
Posted by Per Jessen <pe...@computer.org>.
Henrik K wrote:
> On Sat, Aug 01, 2009 at 11:46:57AM +0200, Per Jessen wrote:
>> Henrik K wrote:
>>
>> > On Sat, Aug 01, 2009 at 12:04:08AM -0700, Linda Walsh wrote:
>> >> Well -- it's not just the cores -- what was the usage of the cores
>> >> that
>> >> were being used? were 3 out the 8 'pegged'? Are these 'real'
>> >> cores, or
>> >> HT cores? In the Core2 and P4 archs, HT's actually slowed down a
>> >> good many workloads unless they were tightly constructed to work
>> >> on the same
>> >> data in cache. Else, those HT's did just enough extra work to
>> >> block cache contents more than anything else.
>> >
>> > I really doubt there's HT involved in a recent looking 8 core 16GB
>> > machine..
>>
>> Why not? I have a couple of brandnew Intel Core i7 (Nehalem) systems
>> with 8Gb RAM - they have 1 physical CPU with 4 cores and HT =
>> 8 "cores". And they've got room for more RAM :-)
>
> Ah a comeback.. I guess it's atleast better than the P4 stuff?
Not sure about that - AFAICT, it's exactly the same technology. (I
haven't done in exhaustive tests though).
/Per Jessen, Zürich
Some benchmarks (Re: Parallelizing Spam Assassin)
Posted by Henrik K <he...@hege.li>.
On Sat, Aug 01, 2009 at 01:34:34PM +0300, Henrik K wrote:
>
> That reminds me, gotta test how SA runs on a Sun T5240 with 16 core "128
> cores"..
Well not that impressive for SA, price/speed wise..
T2+ 2x8x1.4Ghz, 144 msgs/sec @ 128 processes
AMD X4 4x3Ghz, 43 msgs/sec @ 4 processes
Note that this is 3.3 SVN with all the rulesrc included, perl 5.10. I saved
the used stuff at http://sa.hege.li/bench/ to be able to make real
comparisons, if someone has interesting servers. And this is as scientific
as I can bother. :)
Re: Parallelizing Spam Assassin
Posted by Henrik K <he...@hege.li>.
On Sat, Aug 01, 2009 at 11:46:57AM +0200, Per Jessen wrote:
> Henrik K wrote:
>
> > On Sat, Aug 01, 2009 at 12:04:08AM -0700, Linda Walsh wrote:
> >> Well -- it's not just the cores -- what was the usage of the cores
> >> that
> >> were being used? were 3 out the 8 'pegged'? Are these 'real' cores,
> >> or
> >> HT cores? In the Core2 and P4 archs, HT's actually slowed down a
> >> good many workloads unless they were tightly constructed to work on
> >> the same
> >> data in cache. Else, those HT's did just enough extra work to block
> >> cache contents more than anything else.
> >
> > I really doubt there's HT involved in a recent looking 8 core 16GB
> > machine..
>
> Why not? I have a couple of brandnew Intel Core i7 (Nehalem) systems
> with 8Gb RAM - they have 1 physical CPU with 4 cores and HT =
> 8 "cores". And they've got room for more RAM :-)
Ah a comeback.. I guess it's atleast better than the P4 stuff? That reminds
me, gotta test how SA runs on a Sun T5240 with 16 core "128 cores"..
Re: Parallelizing Spam Assassin
Posted by Per Jessen <pe...@computer.org>.
Henrik K wrote:
> On Sat, Aug 01, 2009 at 12:04:08AM -0700, Linda Walsh wrote:
>> Well -- it's not just the cores -- what was the usage of the cores
>> that
>> were being used? were 3 out the 8 'pegged'? Are these 'real' cores,
>> or
>> HT cores? In the Core2 and P4 archs, HT's actually slowed down a
>> good many workloads unless they were tightly constructed to work on
>> the same
>> data in cache. Else, those HT's did just enough extra work to block
>> cache contents more than anything else.
>
> I really doubt there's HT involved in a recent looking 8 core 16GB
> machine..
Why not? I have a couple of brandnew Intel Core i7 (Nehalem) systems
with 8Gb RAM - they have 1 physical CPU with 4 cores and HT =
8 "cores". And they've got room for more RAM :-)
/Per Jessen, Zürich
Re: Parallelizing Spam Assassin
Posted by Henrik K <he...@hege.li>.
On Sat, Aug 01, 2009 at 12:04:08AM -0700, Linda Walsh wrote:
> Well -- it's not just the cores -- what was the usage of the cores that
> were being used? were 3 out the 8 'pegged'? Are these 'real' cores, or
> HT cores? In the Core2 and P4 archs, HT's actually slowed down a good
> many workloads unless they were tightly constructed to work on the same
> data in cache. Else, those HT's did just enough extra work to block cache
> contents more than anything else.
I really doubt there's HT involved in a recent looking 8 core 16GB machine..
> What's the disk I/O look like? I mean don't just focus on idle cores --
> if the wait is on disk, maybe the cores can't get the data fast enough.
As we already guessed, AWL (BerkeleyDB) caused disk I/O and slowness. For
heavy loads you need to use SQL (or maybe the better BDB plugin in 3.3 if we
get it working).
> If the network is involved, well, that's a drag on any message checking.
> I'm seeing times of .3msgs/sec, but I think that's with networking turned
> on. Pretty Ugly.
It affects single messages, but not total throughput. With network checks
you just dedicate a lot more childs. Waiting for network responses takes no
CPU time, thus you can process more messages simultaneously.
Re: Parallelizing Spam Assassin
Posted by Linda Walsh <sa...@tlinx.org>.
Well -- it's not just the cores -- what was the usage of the cores that
were being used? were 3 out the 8 'pegged'? Are these 'real' cores, or
HT cores? In the Core2 and P4 archs, HT's actually slowed down a good
many workloads unless they were tightly constructed to work on the same
data in cache. Else, those HT's did just enough extra work to block cache
contents more than anything else.
What's the disk I/O look like? I mean don't just focus on idle cores --
if the wait is on disk, maybe the cores can't get the data fast enough.
If the network is involved, well, that's a drag on any message checking.
I'm seeing times of .3msgs/sec, but I think that's with networking turned
on. Pretty Ugly.
poifgh wrote:
>
>
> Henrik K wrote:
>> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
>> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
>> used
>> and any nondefault rules/settings? Certainly sounds strange that 1 core
>> could top out the same. Anyone else have figures? Maybe I've borked
>> something myself..
>>
>
> The problem is not with 22 being a low number, but when we have other free
> cores to run different SA parallely why doesnt the throughput scale linearly
> .. I expect for 8 cores with 8 SA running simultaneously the number to be
> 150+ msgs/sec but it is 1/3rd at 50 msgs/sec
>
>
>
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
I havent tried with sa-compile yet - I can give it a shot
--
Henrik K wrote:
>
> On Fri, Jul 31, 2009 at 10:41:47AM -0700, poifgh wrote:
>>
>> Henrik K wrote:
>> >
>> > Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
>> > Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
>> > used
>> > and any nondefault rules/settings? Certainly sounds strange that 1 core
>> > could top out the same. Anyone else have figures? Maybe I've borked
>> > something myself..
>> >
>>
>> The problem is not with 22 being a low number, but when we have other
>> free
>
> I did not say it was a problem. I was just wondering how fast CPU/memory
> you
> have, since my 3Ghz AMD doesn't seem to keep up.
>
> I just tested with fresh 3.2.5 install, and running 500 mail mbox with
> single core resulted in 11 msgs / sec. Then I used sa-compile, and it
> raised
> to 15. Did you use it also?
>
> Of course your mailbox could be a lot different, so hard to compare.
>
>> cores to run different SA parallely why doesnt the throughput scale
>> linearly
>> .. I expect for 8 cores with 8 SA running simultaneously the number to be
>> 150+ msgs/sec but it is 1/3rd at 50 msgs/sec
>
> Anyway as people have already said here, disable AWL:
>
> use_auto_whitelist 0
>
>
>
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24765570.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by jdow <jd...@earthlink.net>.
From: "poifgh" <ab...@gmail.com>
Sent: Friday, 2009/July/31 19:47
>
> I am sorry, I did not provide any statistics of the machine involved.
> CPU - 8 cores with each core 2327 MHz
> RAM - 16GB
> Afair its has 7200RPM disk - 2TB.
One disk.... you might consider a striped array to get disk speed.
50 megabytes per second stresses most disks pretty hard - not to the
limit. But if there is a lot of seeking involved as well as multiple
copies of the files being made as they pass through the system I can
see how it'd be a little rough on the disk throughput.
{^_^}
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
I am sorry, I did not provide any statistics of the machine involved.
CPU - 8 cores with each core 2327 MHz
RAM - 16GB
Afair its has 7200RPM disk - 2TB.
Yes, people were right in indicating AWL could be the problem. turning off
AWL results in near linear scaling of SA as we increase number of processes.
My input is more than a 100K [mostly] spams which allowed me to have each
run last for several minutes and then take an avg to get #msgs/sec
With AWL, bayes and DNSBL turned off - i get about 24 msgs/sec for 1 fork
and 166 msgs/sec for 8 fork
with awl on and bayes and DNSBL off, i get about 22 msgs/sec for 1 fork and
50 msgs/sec for 8 fork
Thnx everyone for helping out.
--
Henrik K wrote:
>
> On Fri, Jul 31, 2009 at 10:41:47AM -0700, poifgh wrote:
>
>
> I did not say it was a problem. I was just wondering how fast CPU/memory
> you
> have, since my 3Ghz AMD doesn't seem to keep up.
>
> I just tested with fresh 3.2.5 install, and running 500 mail mbox with
> single core resulted in 11 msgs / sec. Then I used sa-compile, and it
> raised
> to 15. Did you use it also?
>
> Of course your mailbox could be a lot different, so hard to compare.
>
>> cores to run different SA parallely why doesnt the throughput scale
>> linearly
>> .. I expect for 8 cores with 8 SA running simultaneously the number to be
>> 150+ msgs/sec but it is 1/3rd at 50 msgs/sec
>
> Anyway as people have already said here, disable AWL:
>
> use_auto_whitelist 0
>
>
>
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24765545.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Henrik K <he...@hege.li>.
On Fri, Jul 31, 2009 at 10:41:47AM -0700, poifgh wrote:
>
> Henrik K wrote:
> >
> > Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
> > Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
> > used
> > and any nondefault rules/settings? Certainly sounds strange that 1 core
> > could top out the same. Anyone else have figures? Maybe I've borked
> > something myself..
> >
>
> The problem is not with 22 being a low number, but when we have other free
I did not say it was a problem. I was just wondering how fast CPU/memory you
have, since my 3Ghz AMD doesn't seem to keep up.
I just tested with fresh 3.2.5 install, and running 500 mail mbox with
single core resulted in 11 msgs / sec. Then I used sa-compile, and it raised
to 15. Did you use it also?
Of course your mailbox could be a lot different, so hard to compare.
> cores to run different SA parallely why doesnt the throughput scale linearly
> .. I expect for 8 cores with 8 SA running simultaneously the number to be
> 150+ msgs/sec but it is 1/3rd at 50 msgs/sec
Anyway as people have already said here, disable AWL:
use_auto_whitelist 0
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
Henrik K wrote:
>
> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
> used
> and any nondefault rules/settings? Certainly sounds strange that 1 core
> could top out the same. Anyone else have figures? Maybe I've borked
> something myself..
>
The problem is not with 22 being a low number, but when we have other free
cores to run different SA parallely why doesnt the throughput scale linearly
.. I expect for 8 cores with 8 SA running simultaneously the number to be
150+ msgs/sec but it is 1/3rd at 50 msgs/sec
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24760294.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
Henrik K wrote:
>
> Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
> Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was
> used
> and any nondefault rules/settings? Certainly sounds strange that 1 core
> could top out the same. Anyone else have figures? Maybe I've borked
> something myself..
>
The rules sets were default ..
1. Took a fresh SA download
2. Run [configured number of parallel] SA on a [different giant] mbox file
without DNSBL and 'use_bayes 0' and 'bayes_auto_learn 0'
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24760106.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Henrik K <he...@hege.li>.
On Fri, Jul 31, 2009 at 09:32:42AM +0100, richard@buzzhost.co.uk wrote:
> On Thu, 2009-07-30 at 23:55 -0700, poifgh wrote:
> > Hi
> >
> > I was measuring how quickly could SA [spam assassin] process spams when
> > several SA processes are run in parallel over separate mbox files. I used a
> > 8 core machine. Below are the numbers when I forked different number of
> > processes.
> >
> > Fork = 8;
> > Rate = 57 msgs/sec
> >
> > Fork = 4;
> > Rate = 44 msgs/sec
> >
> > Fork = 1;
> > Rate = 22 msgs/sec
> >
> >
> > I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
> > a linear increase in the throughput? Is a file locking creating the
> > bottleneck? If yes, which particular file is being locked? If no, what could
> > be the reason for this?
> >
> > thnx
> Wow! That's a real flying machine!
Yeah, given that my 4x3Ghz box masscheck peaks at 22 msgs/sec, without
Net/AWL/Bayes. But that's the 3.3 SVN ruleset.. wonder what version was used
and any nondefault rules/settings? Certainly sounds strange that 1 core
could top out the same. Anyone else have figures? Maybe I've borked
something myself..
Re: Parallelizing Spam Assassin
Posted by jdow <jd...@earthlink.net>.
From: "LuKreme" <kr...@kreme.com>
Sent: Friday, 2009/July/31 12:37
> On Jul 31, 2009, at 1:33 PM, jdow wrote:
>> Given that profanity is the effort of a small mind to express itself
>> I have a feeling he's going to receive his third and final warning any
>> time now, Matt
>
> Given that nothing that richard said is not anything I've heard on,
> say, prime time TV or... a committee meeting I am really curious now
> as to what was considered 'obscene'.
>
> I'm quite serious.
>
> Have I stumbled into a list run by religious freaks?
Not me. I can happily go several whole days without hearing the
B word. When I hear it I get B...y.
{^_^} Joanne
Re: Parallelizing Spam Assassin
Posted by John Rudd <jr...@ucsc.edu>.
On Fri, Jul 31, 2009 at 12:37, LuKreme<kr...@kreme.com> wrote:
> On Jul 31, 2009, at 1:33 PM, jdow wrote:
>>
>> Given that profanity is the effort of a small mind to express itself
>> I have a feeling he's going to receive his third and final warning any
>> time now, Matt
>
> Given that nothing that richard said is not anything I've heard on, say,
> prime time TV or... a committee meeting I am really curious now as to what
> was considered 'obscene'.
>
> I'm quite serious.
>
> Have I stumbled into a list run by religious freaks?
(mods: sorry if this also falls into the verboten category, I'm more
trying to explore/catalog than perpetuate)
Maybe it was using the word "bitch", where he could have used the word
"complain".
(and, religious freaks aren't the only freaks that don't like to see
the word "Jesus" used in that kind of context ... saying words like
"Jesus" around atheist freaks can also result in them claiming offence
... luckily religious freaks and atheist freaks aren't as common as
merely religious people and merely atheist people)
Re: Parallelizing Spam Assassin
Posted by LuKreme <kr...@kreme.com>.
On Jul 31, 2009, at 1:33 PM, jdow wrote:
> Given that profanity is the effort of a small mind to express itself
> I have a feeling he's going to receive his third and final warning any
> time now, Matt
Given that nothing that richard said is not anything I've heard on,
say, prime time TV or... a committee meeting I am really curious now
as to what was considered 'obscene'.
I'm quite serious.
Have I stumbled into a list run by religious freaks?
--
Clark's Law: Sufficiently advanced cluelessness is
indistinguishable from malice
Clark Slaw: Anything that has been severely damaged or destroyed
by application of Clark's Law
Re: Parallelizing Spam Assassin
Posted by jdow <jd...@earthlink.net>.
From: "Matt Kettler" <mk...@verizon.net>
Sent: Friday, 2009/July/31 04:26
> richard@buzzhost.co.uk wrote:
>> On Fri, 2009-07-31 at 09:53 +0100, Justin Mason wrote:
>>
>>> On Fri, Jul 31, 2009 at 09:32,
>>> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
>>>
...
>>>>
>>> Richard -- please watch your language. This is a public mailing
>>> list, and offensive language here is inappropriate.
>>>
>>>
...
>>
>>
>>
>>
> Richard, we are not joking. Please watch your language on this mailing
> list, or you will be banned from it.
>
> You have now been warned by 2 members of the Project Management
> Committee. You will not be warned again.
Given that profanity is the effort of a small mind to express itself
I have a feeling he's going to receive his third and final warning any
time now, Matt.
{^_-}
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Fri, 2009-07-31 at 08:25 -0700, John Hardin wrote:
> On Fri, 31 Jul 2009, richard@buzzhost.co.uk wrote:
>
> > ... dropping in here and making jokes at such low hanging fruit.
>
> Make all the jokes at Barracuda's expense that you like, complain about
> them all you like, just avoid offensive language. Vitriol is more
> impressive if you are creative enough to avoid using profanity and
> vulgarity while still blasting your target to pieces.
>
Received and understood.
Re: Parallelizing Spam Assassin
Posted by jdow <jd...@earthlink.net>.
From: "LuKreme" <kr...@kreme.com>
Sent: Friday, 2009/July/31 12:30
> On Jul 31, 2009, at 9:25 AM, John Hardin wrote:
>> On Fri, 31 Jul 2009, richard@buzzhost.co.uk wrote:
>>
>>> ... dropping in here and making jokes at such low hanging fruit.
>>
>> Make all the jokes at Barracuda's expense that you like, complain
>> about them all you like, just avoid offensive language.
>
> Really? Referring to gay hardware is THAT offensive that someone would
> need to be banned over it?
No, it's the word "expensive".
{+_+}
Re: Parallelizing Spam Assassin
Posted by LuKreme <kr...@kreme.com>.
On Jul 31, 2009, at 9:25 AM, John Hardin wrote:
> On Fri, 31 Jul 2009, richard@buzzhost.co.uk wrote:
>
>> ... dropping in here and making jokes at such low hanging fruit.
>
> Make all the jokes at Barracuda's expense that you like, complain
> about them all you like, just avoid offensive language.
Really? Referring to gay hardware is THAT offensive that someone would
need to be banned over it?
--
Is a vegetarian permitted to eat animal crackers?
Re: Parallelizing Spam Assassin
Posted by John Hardin <jh...@impsec.org>.
On Fri, 31 Jul 2009, richard@buzzhost.co.uk wrote:
> ... dropping in here and making jokes at such low hanging fruit.
Make all the jokes at Barracuda's expense that you like, complain about
them all you like, just avoid offensive language. Vitriol is more
impressive if you are creative enough to avoid using profanity and
vulgarity while still blasting your target to pieces.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Vista is at best mildly annoying and at worst makes you want to
rush to Redmond, Wash. and rip somebody's liver out. -- Forbes
-----------------------------------------------------------------------
5 days until the 274th anniversary of John Peter Zenger's acquittal
Re: Parallelizing Spam Assassin
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2009-07-31 at 23:56 -0700, Linda Walsh wrote:
> May I point out, that while you may find the language crude -- it isn't
> language that would violate FTC standards in that in used any of the
> 7 or so 'unmentionable words'...
It's not about words on their own -- it's about how they are being used,
and their meaning in context.
> BTW, I've never even 'heard' or seen his name before this post.
Must have been a warm and cozy place, the rock you've been hiding
under. ;) You missed a 3 digit figure of posts and uncalled-for
off-topic rants within a few weeks.
> If I was talking with [...] I just apply my linguistic filter and
> attempt to get the meaning.
Sic.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Parallelizing Spam Assassin
Posted by Linda Walsh <sa...@tlinx.org>.
May I point out, that while you may find the language crude -- it isn't
language that would violate FTC standards in that in used any of the
7 or so 'unmentionable words'...
People -- these standards of 'crude language' really need to be strongly
held 'in check' -- the US is 'supposed' to be the society of 'free speech'
unless it is obscene or threatening.
I don't think his posting was either (BTW, I've never even 'heard' or seen
his name before this post. All I saw was his 'uk' addr -- and I've known
a few 'uk' types, and many of them sound very crude to an American ear
these days.
So in addition to applying strictures in a conservative manner, we must,
hopefully, try to be sensitive to different cultural backgrounds.
If I was talking with a black teen from downtown SF/Oakland, I'd have to
translate from Eubonics -- which can sound rather crude and might contain
and F-word every other sentence. I just apply my linguistic filter and
attempt to get the meaning. I hardly thing this list is aimed at an young
audience -- and kid 13+ is going to have heard quite an ear-full of 'colorful explicatives' from ST4:Voyage home (a family movie), to everyday peer talk.
Yes -- it sounded crude...more than I, normally hear in America -- but not more than I'd hear in London.
Just my 2-cents on cultural sensitivity, and the ability to be amused at cultural differences (rather than choosing to be offended by them).
p.s. - Most Commercial vendor products are Bantha Poodoo -- especially for
Virus/Security and Spam protection, but NOT all. Usually the highest advertised profile are the worst -- they put more budget into advertising than engineering.
Yeah, I still thing SA is a bit slow, but I put much of that up to it being
written in an interpretive language and it's wide flexibility and extensibility with plug-ins. Whatcha gonna do? Maybe we should rewrite it in Forth?
*grin*...
Re: Parallelizing Spam Assassin
Posted by Matt Kettler <mk...@verizon.net>.
richard@buzzhost.co.uk wrote:
> email me off list as I've just been
> banned for upsetting a sponsor LOL....
>
Richard, this has nothing to do with Barracuda. They have no influence
over my opinions whatsoever. I don't work for Apache or Barracuda, or
any company sponsored by either.Neither Apache nor Barracuda has
complained. At the time I warned you, I didn't even remember that
Barracuda ever donated to Apache. I don't think any member of the PMC
has any regular contact with Barracuda, although we've had occasional
contact about using their RBL.
Your warning is about using foul language, and then choosing to thumb
your nose at the warning Justin gave you. You're behaving like an
impudent and foul mouthed child, and that's unwelcome her.
That said, I really don't appreciate you using this list to rant about
Barracuda's products, or discuss them at all. This is the SpamAssassin
list, not the Barracuda list. Barracuda may use SpamAssassin, and
SpamAssassin may support the Barracuda public RBL, but beyond that, any
discussion of them is, quite frankly, off-topic. I don't care how good
or bad their commercial product, or its support is, because it is
off-topic here. I don't welcome people praising Barracuda any more than
I welcome complaints. It simply doesn't matter to SpamAssassin, so it
doesn't belong here.
You may as well be ranting about Ford cars for all I care, it still
doesn't belongs here.
This list is about SpamAssassin, nothing more, nothing less.
Continue with the foul language, and you'll find the door very quickly.
Keep harping on the same off-topic subject and we will eventually get
tired of it. You've said your peace about Barracuda, now give it a rest,
because frankly I don't care about their products, I care about our product.
Is that difficult to understand?
>
>
>
>
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Fri, 2009-07-31 at 07:26 -0400, Matt Kettler wrote:
> richard@buzzhost.co.uk wrote:
> > On Fri, 2009-07-31 at 09:53 +0100, Justin Mason wrote:
> >
> >> On Fri, Jul 31, 2009 at 09:32,
> >> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
> >>
> >>> Imagine what Barracuda Networks could do with that if they did not fill
> >>> their gay little boxes with hardware rubbish from the floors of MSI and
> >>> supermicro. Jesus, try and process that many messages with a $30,000
> >>> Barracuda and watch support bitch 'You are fully scanning to much mail
> >>> and making our rubbish hardware wet the bed.....' LOL.
> >>>
> >> Richard -- please watch your language. This is a public mailing
> >> list, and offensive language here is inappropriate.
> >>
> >>
> > I apologise for the any language deemed offensive. Whilst 'Jesus',
> > 'Bitch' and 'Wet the bed' are mostly acceptable, I offer no defence for
> > openly swearing and using the filty phrase 'Barracuda Networks'. For
> > this I apologise.
> >
> >
> >
> >
> Richard, we are not joking. Please watch your language on this mailing
> list, or you will be banned from it.
>
> You have now been warned by 2 members of the Project Management
> Committee. You will not be warned again.
>
>
>
I have already apologised. I will not use the words you appear to have
found offensive again. Can I ask, is this actually about the words I
used *or* because of my comments regarding Barracuda Networks? I ask
because I note they made a 'monetary donation' to Apache:
http://www.barracudanetworks.com/ns/company/open-source.php
If you want to ban me I will understand - you need to keep the wheels
greased. It would give me more time to concentrate on leaking all the
Barracuda code into the public domain, along with the various 'warez'
tools I've written for it. This would probably be more beneficial to
Barracuda Customers than dropping in here and making jokes at such low
hanging fruit. If any Barracuda Customer would like to know how to
unlock their barracuda without lifting the lid, or get change the model
serial number and get free e.u. email me off list as I've just been
banned for upsetting a sponsor LOL....
Re: Parallelizing Spam Assassin
Posted by Matt Kettler <mk...@verizon.net>.
richard@buzzhost.co.uk wrote:
> On Fri, 2009-07-31 at 09:53 +0100, Justin Mason wrote:
>
>> On Fri, Jul 31, 2009 at 09:32,
>> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
>>
>>> Imagine what Barracuda Networks could do with that if they did not fill
>>> their gay little boxes with hardware rubbish from the floors of MSI and
>>> supermicro. Jesus, try and process that many messages with a $30,000
>>> Barracuda and watch support bitch 'You are fully scanning to much mail
>>> and making our rubbish hardware wet the bed.....' LOL.
>>>
>> Richard -- please watch your language. This is a public mailing
>> list, and offensive language here is inappropriate.
>>
>>
> I apologise for the any language deemed offensive. Whilst 'Jesus',
> 'Bitch' and 'Wet the bed' are mostly acceptable, I offer no defence for
> openly swearing and using the filty phrase 'Barracuda Networks'. For
> this I apologise.
>
>
>
>
Richard, we are not joking. Please watch your language on this mailing
list, or you will be banned from it.
You have now been warned by 2 members of the Project Management
Committee. You will not be warned again.
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Fri, 2009-07-31 at 09:53 +0100, Justin Mason wrote:
> On Fri, Jul 31, 2009 at 09:32,
> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
> > Imagine what Barracuda Networks could do with that if they did not fill
> > their gay little boxes with hardware rubbish from the floors of MSI and
> > supermicro. Jesus, try and process that many messages with a $30,000
> > Barracuda and watch support bitch 'You are fully scanning to much mail
> > and making our rubbish hardware wet the bed.....' LOL.
>
> Richard -- please watch your language. This is a public mailing
> list, and offensive language here is inappropriate.
>
I apologise for the any language deemed offensive. Whilst 'Jesus',
'Bitch' and 'Wet the bed' are mostly acceptable, I offer no defence for
openly swearing and using the filty phrase 'Barracuda Networks'. For
this I apologise.
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Fri, 2009-07-31 at 23:40 -0700, Linda Walsh wrote:
> It's an American thing. Things that are normal speech for UK blokes, get
> Americans all disturbed.
I'm sure that is mostly it, Linda. They don't seem to 'get' it.
Two things I observe in this whole 'barracuda-gate' posting;
1. Being 'offended' is not terminal, it does not kill, disable or have any side effects.
Can you image going to a doctor and saying "You've got to treat me Doctor, I got offended,
my feelings are hurt."
2. Cultural differences exist. If I am expected to respect the 'diversity' that has people
jumping up and down about the use of 'gay' because *they* have a different meaning for it,
it is not unreasonable to expect *them* to respect my diversity in using it in it's original context.
I'm tired of being told not to offend or upset people who don't show my views and beliefs equal respect.
Anyway, it's all OT and pointless in any context of processing spam - the point I made was factual love it or hate it.
That was poor hardware spec used in a well known retail anti-spam appliance = 6-8 MPS 'fully scanned'.
Re: Parallelizing Spam Assassin
Posted by Dan Schaefer <da...@performanceadmin.com>.
This whole time I thought the subject line was "Paralyzing Spam
Assassin" and the original poster was having trouble with SA locking up.
Oops. ;-)
--
Dan Schaefer
Web Developer/Systems Analyst
Performance Administration Corp.
Re: Parallelizing Spam Assassin
Posted by Matt Kettler <mk...@verizon.net>.
Um, Linda.. I'm pretty positive Justin is Irish, not American.
Linda Walsh wrote:
> It's an American thing. Things that are normal speech for UK blokes, get
> Americans all disturbed.
>
> Funny, used to be the other way around...but well...times change.
>
>
>
> Justin Mason wrote:
>> On Fri, Jul 31, 2009 at 09:32,
>> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
>>> Imagine what Barracuda Networks could do with that if they did not fill
>>> their gay little boxes with hardware rubbish from the floors of MSI and
>>> supermicro. Jesus, try and process that many messages with a $30,000
>>> Barracuda and watch support bitch 'You are fully scanning to much mail
>>> and making our rubbish hardware wet the bed.....' LOL.
>>
>> Richard -- please watch your language. This is a public mailing
>> list, and offensive language here is inappropriate.
>>
>
>
Re: Parallelizing Spam Assassin
Posted by Patrick Ben Koetter <p...@state-of-mind.de>.
* Linda Walsh <sa...@tlinx.org>:
> It's an American thing. Things that are normal speech for UK blokes, get
> Americans all disturbed.
Sloppy language is sloppy language everywhere! I took offense in the message,
too and I am neither American nor am I from the UK.
But what annoys me the most is that the comments were simply off-topic. I can
go and meet some friends and I can happily spend the whole night cracking one
joke after another - pc or not pc.
There's a place of everything. This is the place for SpamAssassin. I wish we
could get back to what this thread was all about: "Parallelizing
SpamAssassin".
p@rick
> Funny, used to be the other way around...but well...times change.
>
> Justin Mason wrote:
> >On Fri, Jul 31, 2009 at 09:32,
> >richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
> >>Imagine what Barracuda Networks could do with that if they did not fill
> >>their gay little boxes with hardware rubbish from the floors of MSI and
> >>supermicro. Jesus, try and process that many messages with a $30,000
> >>Barracuda and watch support bitch 'You are fully scanning to much mail
> >>and making our rubbish hardware wet the bed.....' LOL.
> >
> >Richard -- please watch your language. This is a public mailing
> >list, and offensive language here is inappropriate.
> >
--
state of mind
Digitale Kommunikation
http://www.state-of-mind.de
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Re: Parallelizing Spam Assassin
Posted by Linda Walsh <sa...@tlinx.org>.
It's an American thing. Things that are normal speech for UK blokes, get
Americans all disturbed.
Funny, used to be the other way around...but well...times change.
Justin Mason wrote:
> On Fri, Jul 31, 2009 at 09:32,
> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
>> Imagine what Barracuda Networks could do with that if they did not fill
>> their gay little boxes with hardware rubbish from the floors of MSI and
>> supermicro. Jesus, try and process that many messages with a $30,000
>> Barracuda and watch support bitch 'You are fully scanning to much mail
>> and making our rubbish hardware wet the bed.....' LOL.
>
> Richard -- please watch your language. This is a public mailing
> list, and offensive language here is inappropriate.
>
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Fri, 2009-07-31 at 17:37 -0400, Glenn Sieb wrote:
> LuKreme said the following on 7/31/09 3:27 PM:
> >> Richard -- please watch your language. This is a public mailing
> >> list, and offensive language here is inappropriate.
> >
> > I dunno, 'gay' isn't that offensive.
> >
> >
>
> Gay is *not* a synonym for stupid.
>
> I do take offense to the term being used in that manner.
>
> --Glenn
>
I find it deeply offensive that the word 'gay' is used as a synonym for
homosexual in an attempt to stop people from using 'queer' - but hey
'gays' are not the only ones with opinions that 'matter'.
Gay **is** a synonym for 'stupid' (silly) as far as I am concerned. It's
original meaning of 'carefree','happy','silly' and 'showy' are clearly
being used with sarcasm. The fact is 'queers' hijacked the word as per
this;
"— USAGE Gay is now a standard term for ‘homosexual’, and is the term
preferred by homosexual men to describe themselves. As a result, it is
now very difficult to use gay in its earlier meanings ‘carefree’ or
‘bright and showy’ without arousing a sense of double entendre. Gay in
its modern sense typically refers to men, lesbian being the standard
term for homosexual women."
http://www.askoxford.com/concise_oed/gay?view=uk
So please *quit* with the sympathetic pink preaching and learn what the
word actually means. Just because it "is the term preferred by
homosexual men to describe themselves" does not mean a minority have the
right to slate people who use the word properly.
With regards to the dig about Barracuda - this *WAS* OT. There were some
benchmark tests discussed here that were impressive. My experience of SA
in daily production is on Barracuda Appliances that ****STRUGGLE**** to
push 6-8 messages a second through, so it was relevant as comparison.
The wording could have been chosen with more care and I apologise to
Christians or dog lovers who found the use of the messiah or female form
offensive. However, the use of gay in a sarcastic context clearly fits
with the original origin of the word, not by that section of the society
who have stolen it and made it OT and OM. For that I make ***NO***
apology. I appreciate that using 'gay' in it's real meaning may hurt the
feelings of some 'homosexuals' but as I have to respect their choices
and views, they should show *me* the same respect for *my* views and
choices. You may not like who I am and what I do, I may not like who you
are and what you do.
Now do we need to continue this or throw little tin God banning threats
around more or can we just *get along* knowing we are all different but
frequenting this list for Spamassassin information ?
Re: Parallelizing Spam Assassin
Posted by Glenn Sieb <ge...@wingfoot.org>.
LuKreme said the following on 7/31/09 3:27 PM:
>> Richard -- please watch your language. This is a public mailing
>> list, and offensive language here is inappropriate.
>
> I dunno, 'gay' isn't that offensive.
>
>
Gay is *not* a synonym for stupid.
I do take offense to the term being used in that manner.
--Glenn
Re: Parallelizing Spam Assassin
Posted by LuKreme <kr...@kreme.com>.
On Jul 31, 2009, at 2:53 AM, Justin Mason wrote:
On Fri, Jul 31, 2009 at 09:32,
> richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
>> Imagine what Barracuda Networks could do with that if they did not
>> fill
>> their gay little boxes with hardware rubbish from the floors of MSI
>> and
>> supermicro. Jesus, try and process that many messages with a $30,000
>> Barracuda and watch support bitch 'You are fully scanning to much
>> mail
>> and making our rubbish hardware wet the bed.....' LOL.
>
> Richard -- please watch your language. This is a public mailing
> list, and offensive language here is inappropriate.
I dunno, 'gay' isn't that offensive.
--
Overhead, without any fuss, the stars were going out.
Re: Parallelizing Spam Assassin
Posted by Justin Mason <jm...@jmason.org>.
On Fri, Jul 31, 2009 at 09:32,
richard@buzzhost.co.uk<ri...@buzzhost.co.uk> wrote:
> Imagine what Barracuda Networks could do with that if they did not fill
> their gay little boxes with hardware rubbish from the floors of MSI and
> supermicro. Jesus, try and process that many messages with a $30,000
> Barracuda and watch support bitch 'You are fully scanning to much mail
> and making our rubbish hardware wet the bed.....' LOL.
Richard -- please watch your language. This is a public mailing
list, and offensive language here is inappropriate.
--
--j.
Re: Parallelizing Spam Assassin
Posted by "richard@buzzhost.co.uk" <ri...@buzzhost.co.uk>.
On Thu, 2009-07-30 at 23:55 -0700, poifgh wrote:
> Hi
>
> I was measuring how quickly could SA [spam assassin] process spams when
> several SA processes are run in parallel over separate mbox files. I used a
> 8 core machine. Below are the numbers when I forked different number of
> processes.
>
> Fork = 8;
> Rate = 57 msgs/sec
>
> Fork = 4;
> Rate = 44 msgs/sec
>
> Fork = 1;
> Rate = 22 msgs/sec
>
>
> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
> a linear increase in the throughput? Is a file locking creating the
> bottleneck? If yes, which particular file is being locked? If no, what could
> be the reason for this?
>
> thnx
Wow! That's a real flying machine!
Imagine what Barracuda Networks could do with that if they did not fill
their gay little boxes with hardware rubbish from the floors of MSI and
supermicro. Jesus, try and process that many messages with a $30,000
Barracuda and watch support bitch 'You are fully scanning to much mail
and making our rubbish hardware wet the bed.....' LOL.
Well done you!
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
I did that - with DNSBL off there are no port 53 communications from SA
--
Jason Philbrook wrote:
>
> I would run a tcpdump on the ethernet interface while doing this, just
> in case there are network tests happening that you are not aware of.
>
> On Thu, Jul 30, 2009 at 11:55:21PM -0700, poifgh wrote:
>>
>> Hi
>>
>> I was measuring how quickly could SA [spam assassin] process spams when
>> several SA processes are run in parallel over separate mbox files. I used
>> a
>> 8 core machine. Below are the numbers when I forked different number of
>> processes.
>>
>> Fork = 8;
>> Rate = 57 msgs/sec
>>
>> Fork = 4;
>> Rate = 44 msgs/sec
>>
>> Fork = 1;
>> Rate = 22 msgs/sec
>>
>>
>> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not
>> seeing
>> a linear increase in the throughput? Is a file locking creating the
>> bottleneck? If yes, which particular file is being locked? If no, what
>> could
>> be the reason for this?
>>
>> thnx
>> --
>> View this message in context:
>> http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24751958.html
>> Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
>
> --
> /*
> Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL
> KB1IOJ | Broadband Internet Access, Dialup, and Hosting
> http://f64.nu/ | for Midcoast Maine http://www.midcoast.com/
> */
>
>
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24796555.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by jp <jp...@saucer.midcoast.com>.
I would run a tcpdump on the ethernet interface while doing this, just
in case there are network tests happening that you are not aware of.
On Thu, Jul 30, 2009 at 11:55:21PM -0700, poifgh wrote:
>
> Hi
>
> I was measuring how quickly could SA [spam assassin] process spams when
> several SA processes are run in parallel over separate mbox files. I used a
> 8 core machine. Below are the numbers when I forked different number of
> processes.
>
> Fork = 8;
> Rate = 57 msgs/sec
>
> Fork = 4;
> Rate = 44 msgs/sec
>
> Fork = 1;
> Rate = 22 msgs/sec
>
>
> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
> a linear increase in the throughput? Is a file locking creating the
> bottleneck? If yes, which particular file is being locked? If no, what could
> be the reason for this?
>
> thnx
> --
> View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24751958.html
> Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
--
/*
Jason Philbrook | Midcoast Internet Solutions - Wireless and DSL
KB1IOJ | Broadband Internet Access, Dialup, and Hosting
http://f64.nu/ | for Midcoast Maine http://www.midcoast.com/
*/
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
Bernd Petrovitsch wrote:
>
> On Thu, 2009-07-30 at 23:55 -0700, poifgh wrote:
> [...]
>> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not
>> seeing
>> a linear increase in the throughput? Is a file locking creating the
> Because the bottleneck is not (only) the CPUs?
> Run `vmstat 1` or similar to see (or at least get an idea;-) if the
> workload is I/O bound or CPU-bound or ....
>
>> bottleneck? If yes, which particular file is being locked? If no, what
>> could
> Maybe. The default "store in files" drivers locks the DBs exclusively
> for each access.
>
>> be the reason for this?
> Switch the DB backend to some MySQL or PostgreSQL (or whatever you like
> using from the "supported" ones). Run that on the very same machine and
> compare the numbers with the above.
>
Running 'top' with a single SA process running gives 12.5% CPU utilization
which makes sense since one core is fully utilized at this point out of 8
cores. The SA process reports 100% util for that CPU
When fork goes to 8, each individual CPU is utilized from 30-70% mostly
staying about 30 and only a few reaching 70.
I can vmstat to check out the IO which I dont think should be a problem -
the disks are fast enough to deliver order of magnitudes more reads than 50
msgs/sec.
Can you elaborate on 'store in files'? What are these files, what are they
used for - can they be turned off?
Thnx
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24760163.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Bernd Petrovitsch <be...@firmix.at>.
On Thu, 2009-07-30 at 23:55 -0700, poifgh wrote:
[...]
> I was measuring how quickly could SA [spam assassin] process spams when
> several SA processes are run in parallel over separate mbox files. I used a
> 8 core machine. Below are the numbers when I forked different number of
> processes.
>
> Fork = 8;
> Rate = 57 msgs/sec
>
> Fork = 4;
> Rate = 44 msgs/sec
>
> Fork = 1;
> Rate = 22 msgs/sec
>
>
> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
> a linear increase in the throughput? Is a file locking creating the
Because the bottleneck is not (only) the CPUs?
Run `vmstat 1` or similar to see (or at least get an idea;-) if the
workload is I/O bound or CPU-bound or ....
> bottleneck? If yes, which particular file is being locked? If no, what could
Maybe. The default "store in files" drivers locks the DBs exclusively
for each access.
> be the reason for this?
Switch the DB backend to some MySQL or PostgreSQL (or whatever you like
using from the "supported" ones). Run that on the very same machine and
compare the numbers with the above.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Re: Parallelizing Spam Assassin
Posted by Justin Mason <jm...@jmason.org>.
hi -- turn off Bayes and AWL.
On Fri, Jul 31, 2009 at 07:55, poifgh<ab...@gmail.com> wrote:
>
> Hi
>
> I was measuring how quickly could SA [spam assassin] process spams when
> several SA processes are run in parallel over separate mbox files. I used a
> 8 core machine. Below are the numbers when I forked different number of
> processes.
>
> Fork = 8;
> Rate = 57 msgs/sec
>
> Fork = 4;
> Rate = 44 msgs/sec
>
> Fork = 1;
> Rate = 22 msgs/sec
>
>
> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not seeing
> a linear increase in the throughput? Is a file locking creating the
> bottleneck? If yes, which particular file is being locked? If no, what could
> be the reason for this?
>
> thnx
> --
> View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24751958.html
> Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
>
>
--
--j.
Re: Parallelizing Spam Assassin
Posted by poifgh <ab...@gmail.com>.
c. r. wrote:
>
> On Thu, Jul 30, 2009 at 11:55:21PM -0700, poifgh wrote:
>> Why am I not seeing a linear increase in the throughput?
>> Is a file locking creating the bottleneck?
>
> Maybe the auto white list.
>
> --
>
I can try turning off AWL and get back here..
Thnx
--
View this message in context: http://www.nabble.com/Parallelizing-Spam-Assassin-tp24751958p24760203.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Parallelizing Spam Assassin
Posted by Christian Recktenwald <sp...@citecs.de>.
On Thu, Jul 30, 2009 at 11:55:21PM -0700, poifgh wrote:
> Why am I not seeing a linear increase in the throughput?
> Is a file locking creating the bottleneck?
Maybe the auto white list.
--
Re: Parallelizing Spam Assassin
Posted by Michael Parker <pa...@pobox.com>.
On Jul 31, 2009, at 1:55 AM, poifgh wrote:
>
> I ran freshly build SA with Bayes and DNSBL turned off. Why am I not
> seeing
> a linear increase in the throughput? Is a file locking creating the
> bottleneck? If yes, which particular file is being locked? If no,
> what could
> be the reason for this?
There could be many reasons, check out my talk (admittedly out of date
a little but should still be mostly relevant) on High Performance
Apache SpamAssassin at the following link:
http://people.apache.org/~parker/presentations/index.html
Keep in mind that you might also be seeing other factors like memory
and disk I/O contention. You don't really spell out your testing
infrastructure so its not real clear if you're even performing a valid
test.
Also, I wouldn't necessarily expect to see a linear increase, although
you might be able to take some easy steps for increasing your overall
performance.
Michael