Bro load with no traffic

Zeek
1

Does anyone know why Bro would be using resources when no traffic flowing to the sensor?
Recently we were having some ECC errors on one of our sensors and turned off the traffic to that sensor for troubleshooting purposes.
Noticed that the load was pretty high (~7) on that sensor, and was wondering what Bro must be doing that would cause that load, shouldn’t it be just waiting for the packets without using much cpu/memory resources on the box?

Stats when no traffic flowing to the sensor, bro processes running because of cron on manager kicking the bro processes on the workers:

$ top
top - 12:18:17 up 13 days, 19:12, 2 users, load average: 6.72, 7.05, 7.34
Tasks: 555 total, 9 running, 546 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.7 us, 5.7 sy, 0.0 ni, 84.5 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 13191564+total, 95957600 free, 32708392 used, 3249652 buff/cache
KiB Swap: 8388600 total, 8388600 free, 0 used. 98285016 avail Mem

When the traffic was turned back on, load average:

$ top
top - 10:39:52 up 1 day, 19:02, 2 users, load average: 12.89, 12.89, 12.82
Tasks: 551 total, 11 running, 540 sleeping, 0 stopped, 0 zombie
%Cpu(s): 20.9 us, 6.1 sy, 0.1 ni, 72.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 11540057+total, 59135456 free, 52346920 used, 3918204 buff/cache
KiB Swap: 8388600 total, 8388600 free, 0 used. 62253548 avail Mem

Any thoughts? :slight_smile:

Thanks,
Fatema

2

Currently, Bro's main loop never completely idles in absence of input,
so something on the order of 5% cpu usage in absence of network
traffic might still be "normal". Also note that that packets aren't
the only input source. As an example, if you shut off traffic
suddenly, but had a large backlog of Broker messages or continues to
send/recv remote messages, that could be processing resources that Bro
continues to use for some time. The event engine also continues on
with any scheduled events, etc.

So not particularly unexpected to hear there's some load in absence of
packets, but hard to say specifically what causes the load in this
case -- you may need to profile/trace if you're really interested.

- Jon

3

Thanks Jon, makes sense now.
I will see if we would want to deep dive into finding out what exactly causing the load. :slight_smile:

Fatema.

4

If you are on 2.5.x and not master, this should still work:

http://mailman.icsi.berkeley.edu/pipermail/bro/2016-November/011010.html

I wouldn't bother using it on a production system though.

5

What Jon said.

There was a patch from Justin that lowered the load for embedded systems. It’s not really an issue on most / any production systems I’ve seen.

6

Sweet… the patch looks interesting to deploy. Thanks!
The load is really not an issue in production for us, as the boxes are pretty beefy with good amount of resources, which never get utilized to it’s full capacity,
but was just curious to know the reason for the high load when the bro workers are idle (just wanted to make sure it’s not some hardware, ex. ECC errors of memory, that’s going bad) :slight_smile:

Thanks!
Fatema.