[Snort-users] pcre high cpu usage

Tomas Heredia tomas.heredia at ...12297...
Tue Oct 19 09:49:05 EDT 2010


 El 18/10/2010 08:13 p.m., Alex Kirk escribió:
>
>     config pcre_match_limit 25
>     onfigpcre_match_limit_recursion 25
>
>     But I don't think it's a good idea. Is it?
>
>  
> No, that's a terrible idea. You might as well just disable all the
> rules that use PCRE if you set a limit that low.
I'va already been thinking about that :-)
>
> Chances are high, based on the collective experience of the group,
> that you've got a small number of rules hogging a large amount of
> processing power, and if you can identify them and either tune or
> disable them, you'll be in way better shape. To ID them, you'll want
> to enable:
>
> config profile_rules: print 50, sort avg_ticks
>
> This will print the top 50 worst offending rules, in order of the
> average number of CPU "ticks" it takes to run them, on exit. See the
> README.PerfProfiling file and the list archives for more information
> if you need it.
Thanks!
I was olready analyzing performance profiling, but looking at total
ticks bu rule (and preproc). That made me lower the overall CPU usage...
But avg-ticks was what I needed to identify delays.
Thanks Again!

BTW: most offending rules (with like 10000 ticks avg!!) were 4676 and
4677, related to Oracle Enterprise Manager. They had the destination
restricted to the only OEM in the net, but that was enough to cause that
delays... May be it's time to think in PCRE ofloading! :-)
Best regards,
Tomás

>
>
> -- 
> Alex Kirk
> AEGIS Program Lead
> Sourcefire Vulnerability Research Team
> +1-410-423-1937
> alex.kirk at ...1935... <mailto:alex.kirk at ...1935...>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20101019/d425db37/attachment.html>


More information about the Snort-users mailing list