[Snort-users] cpu usage by component
mkettler at ...4108...
Thu Sep 11 10:08:58 EDT 2003
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
> > 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.
More information about the Snort-users