Re: cpu usage by component

[Jeff Nathan <jeff () snort org>]

-----BEGIN PGP SIGNED MESSAGE-----
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQE/X/nXEqr8+Gkj0/0RAq8YAJ91A2EumM11Hbc10wtOQBSNQz/SugCeJ/9y
7v2A0/HsFAsWJF1V5WvEuuM=
=7ly7
-----END PGP SIGNATURE-----



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