Re: Pin snort single processor

[Will Metcalf <william.metcalf () gmail com>]

Hmmm I think it can affect anything having to do with rate based
alerting i.e. portscan detection or thresholding based on tracking
src/dst ip addresses.  I'm making the assumption that you are dividing
up traffic using a bpf that was previously being watched by a single
snort process.

This is not a trivial task for something like a fully loaded /24
server farm or something. Another thing to note is that while there
are performance advantages to be had by ensuring locality of traffic
to a core, you have to make sure that you are smarter than the
scheduler i.e. make sure you don't end up in a situation where a
process pinned to a CPU that is pegged at 100% and four cores sitting
at 10% utilization or something.

 ***Sham-less Plug Alert*** In suricata we have multiple ways of
dividing up traffic an pining across cores.  We can do this in
userland based on flow, or we can even take advantage of the PF_RING
clusters to divide up traffic in a flow-based or round-robin mode.
While flow-pinning helps alleviate some of the guess work of traffic
distribution, depending on your network you can still pretty easily
end up in a situation where you have uneven distribution of traffic
across your snort procs or in our case threads.

With that being said, regardless of how you cut your traffic you
should probably ensure that init and it's children have proper
affinity set and stays away from the cores you want to dedicate to IDS
otherwise the scheduler might decide that one of your IDS cores looks
pretty sweet for process migration.

Regards,

Will

2010/4/6 Edward Bjarte Fjellskål <edward.fjellskal () redpill-linpro com>:
> Jason Wallace wrote:
> > OK so there is no affect on tracking frags, state, or anything else
> > that might adversely affect detection. It is just a performance
> > recommendation for folks using more than one instance of Snort?
>
> I would say its a performance recommendation for folks concerned
> about performance regardless of # of snort instances :)
> It does not affect detection other than it might help on lowering
> your packet-loss rate (if you have any).
>
> Snort should stick to one CPU preferably for optimal performance.
> That said, there are other ways to tweak snort that should be
> done first. Also, if you dont have any performance issues, you
> dont have to tune anything :)
>
> Ref:
> http://www.gamelinux.org/?p=81
>
>
> > Thx,
> > Wally
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users