[Snort-users] Pattern Matcher Performance (config detection)
Mike Lococo
mikelococo at ...11827...
Thu Feb 24 16:04:12 EST 2011
On 02/24/2011 03:30 PM, Martin Holste wrote:
>> * I run a large ruleset of over 7000 rules from VRT and ET on a link
>> that peaks at about 1.8gigabits per second each day.
>> * Running snort compiled with --enable-perfprofiling shows
>> that the pattern-matcher accounts for about 80% of snort's
>> CPU time using ac-split.
>> * Switching from ac-split to ac-bnfa increased by CPU usage by
>> about 20%, but decreased ram usage by a few hundred megs per process.
>> * Switching from ac-split to ac-nq decreased CPU usage by about 30%,
>> but increased RAM usage by some unknown amount.
>
> So are you inferring that you are running 7000 rules on a 1.8 gig link
> on a single snort instance and aren't always at 100% CPU? If that's
> the case, then either you have very little HTTP traffic in your 1.8
> gig link, or you're not monitoring what you think you're monitoring
> (BPF filtering, etc.). Any Snort instance with more than 1000 rules
> will be overwhelmed at 200-300 Mb/sec of HTTP traffic no matter which
> pattern matcher you're using. You can up your Mb/sec a bit with an
> Endace card, PF_RING, and a few other tricks, but you can't even run
> 1.8 gig through the preprocessors without hitting 100% CPU. I would
> love to be wrong about this, but it's going to take a lot to convince
> me that you're achieving anywhere near that throughput on a single
> instance.
I probably should have mentioned that I'm using 4-instances with Endace
hardware and ~300MB/process buffers to get this throughput. The CPU's
are pretty-well maxed out during the daily-peak, and I drop some packets
but well under a percent when averaged-out. I also manually tuned out
many of the worst-performing rules/rule-classes which may explain why
I'm a little higher than your 200-300mbit ceiling (which is pretty
accurate in my experience but I've pushed this box a bit further with
manual tuning).
My traffic and protocol distribution is common for higher-ed if you're
familiar with that space. It looks more or less like ISP traffic with a
extra few high-speed transfers. HTTP is either first or second protocol
in terms of bits/sec, so these rates don't come from a weird protocol
distribution that results in lots and lots of packets essentially not
getting inspected.
Cheers,
Mike Lococo
More information about the Snort-users
mailing list