[Snort-users] cpu usage by component

Jeff Nathan jeff at ...950...
Thu Sep 11 10:34:21 EDT 2003

Hash: SHA1

On Tuesday, September 9, 2003, at 11:04 AM, Matt Kettler wrote:

> I can't speak authoritatively, however based on my experience:
> conversation and portscan2 as a collective pair seem to use more 
> memory and CPU than anything else in snort by a factor of at least 4. 
> Based on what they do I can't quite understand why, but on low cpu 
> power systems these two cause extreme packet loss (>10%), even when 
> monitoring a mere 2mbit/sec link on a p-133 that was dedicated to 
> snort. Disabling those two caused the packet loss rate to drop by a 
> factor of 100 (from >10% to approximately 0.1%).
> Based on what it does, I would venture to guess the stream4 
> preprocessor is about as much CPU time as a few case-insensitive 
> content searches. However, I would have expected the same of 
> conversation and portscan2 and clearly their usage is significantly 
> higher. However, stream4 doesn't seem to present a problem for low-end 
> hardware, so my expectations are probably within reason.

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.

> 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.

> 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.
- --
http://cerberus.sourcefire.com/~jeff       (gpg key available)
"Problems cannot be solved at the same level of awareness that
created them."   - Albert Einstein

Version: GnuPG v1.2.2 (Darwin)


More information about the Snort-users mailing list