Re: cpu usage by component

[Matt Kettler <mkettler () evi-inc com>]

At 12:28 AM 9/11/2003 -0400, Jeff Nathan wrote:
> An empirical way to measure the performance of Snort is to use gprof.
> Compile Snort with the profiling options and then let it run for a good 
> log while.  Look at the call graph when you're done and you can see what 
> Snort spends its time doing.

Agreed. However, I'm lazy so I was only offering educated ball-park guesses 
:) However your suggestion is a good one, I often forget that not everyone 
knows that profilers exist. :)


> > Getting packets from the NIC can be either easy or extremely painful 
> depending on your NIC design. However assuming you're using something of 
> reasonably efficient design (ie: not a realtek chipset) this shouldn't be 
> that much of the CPU time. Cross-overs from kernel to user-space are a 
> bit pricey, but the rule engine should be considerably more expensive CPU wise.
>
> I/O is a major issue, but Snort can't do much about that in terms of 
> running in userspace.

True. It's outside of snort's control entirely, but it also relevant to be 
aware of when trying to find ways of tuning a snort box. It's almost 
completely pointless to try to tune snort's settings if your nic is an 
ancient 8bit ISA card that requires CPU driven I/O (non-mastering), because 
99% of the cpu time will be the OS spoon-feeding the NIC.

On the other hand a very nice PCI busmastering NIC with flexible memory 
alignment requirements and efficient PCI bus usage could do this all with 
relatively little CPU involvement, mostly dominated by a single memcpy and 
a context switch.

Of course, that's an extreme example, but it does illustrate that at some 
level the biggest blockage might be your NIC, and in other configurations 
it's less of an issue.



> > I know I'm not giving you any hard numbers, by my expectations would be 
> that the CPU usage would probably break down something along these lines, 
> ignoring conversation/portscan2 which would easily make these numbers 
> insignificant.
> >
> > rules engine - 70% (assuming a fair amount of content searching caused 
> by the traffic profile).
> > stream4 - 15% (assuming some processing an a memcopy to buffer the data)
> > kernel copy to userspace - 10% (assuming most of the work is a memcopy 
> and a context switch)
> > nic management 5% (assuming that a double-copy isn't required due to 
> inefficient busmastering alignments)
>
> The call graphs will, of course, differ from operating system to operating 
> system and across hardware platforms.

Certainly, and also dependant on how your HOME_NET and EXTERNAL_NET are set 
and what your traffic load looks like.

There's a lot of variables that could make those numbers vary wildly. They 
are strictly a wild guess based on a large number of very, very gross 
assumptions, and little knowledge of the snort code itself.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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