I finally had an opportunity to install a Bro 2.5 cluster in the lab for review and was surprised to see a higher CPU usage than 2.4 deployments.
A clean install with (w/ PF_RING) never drops below 25% CPU per worker at idle, meaning I’ve disabled the SPAN traffic and Bro stays at 25%.
I then went as far as disabling every default script except for the following:
@load misc/loaded-scripts
@load tuning/defaults
@load misc/capture-loss
@load misc/profiling.bro
@load misc/stats
And the CPU remains at 25%.
Has anyone experienced similar results with 2.5?
-Dave
Bro doesn't do a great job of using low amounts of CPU at low data rates - it's more tweaked for a constant packet rate.
I use the following patch at home (it applies on 2.4-2.5) which reduces cpu quite a bit when traffic rates are extremely low
--- a/bro-2.4/src/iosource/Manager.cc
+++ b/bro-2.4/src/iosource/Manager.cc
@@ -137,7 +137,7 @@
// decrease CPU load. I guess that's because it allows
// the kernel's packet buffers to fill. - Robin
timeout.tv_sec = 0;
- timeout.tv_usec = 20; // SELECT_TIMEOUT;
+ timeout.tv_usec = 2000; // SELECT_TIMEOUT;
select(0, 0, 0, 0, &timeout);
}
--- a/bro-2.4/src/Net.cc
+++ b/bro-2.4/src/Net.cc
@@ -359,7 +359,7 @@
if ( ! communication_enabled )
usleep(100000);
else
- usleep(1000);
+ usleep(10000);
// Flawfinder says about usleep:
//
--- a/bro-2.4/src/threading/MsgThread.cc
+++ b/bro-2.4/src/threading/MsgThread.cc
@@ -234,7 +234,7 @@
}
if ( ! Killed() )
- usleep(1000);
+ usleep(10000);
}
signal_val = old_signal_val;
Thanks Justin, The patch should be perfect for home/lab deployments. A tight ‘select loop’ looks like the exact culprit:
% time seconds usecs/call calls errors syscall
63.26 0.053786 0 307412 select
36.74 0.031237 0 153591 nanosleep
0.00 0.000000 0 157 127 read
0.00 0.000000 0 153 write
0.00 0.000000 0 2 stat
0.00 0.000000 0 16 kill
0.00 0.000000 0 8 getrusage
0.00 0.000000 0 1 restart_syscall
100.00 0.085023 461340 127 total
-Dave
Thanks again Justin, the CPU now sits down around 3% on extremely low traffic links.
Is this something worthy of a feature request for low bandwidth setups?
In addition to something like this, I have to do a patch for very low network traffic with bro cron reporting network traffic has stopped on the monitoring interface.
Regarding broctl, you can disable the "not seeing any packets"
warnings if you set this in your etc/broctl.cfg:
StatsLogEnable = 0
Doing so will also disable logging to broctl's stats.log (note:
this is NOT the stats.log that Bro itself logs), which I'm
guessing most people don't need anyway.
Would it be possible for someone quantify what a low bandwidth/low traffic setup might be in terms of a bandwidth unit of measurement range where Justin’s patch would be advised to be used? I.E. Kbps/Mbps etc. What would be a cut-off bandwidth/traffic rate value where it would not be advisable that this patch be used?