Brocontrol revisited

Zeek
1

Morning all (least where I’m at),

So…when I very first started with bro, I noticed that running brocontrol vs. just bro I noticed a large difference in cpu usage. This morning I decided to revisit brocontrol. When running bro commandline I see:

top - 05:31:35 up 5 min, 2 users, load average: 0.30, 0.70, 0.38
Tasks: 95 total, 2 running, 93 sleeping, 0 stopped, 0 zombie
%Cpu(s): 11.3 us, 23.8 sy, 0.0 ni, 64.5 id, 0.0 wa, 0.4 hi, 0.0 si, 0.0 st
KiB Mem: 3082108 total, 2562596 used, 519512 free, 29828 buffers
KiB Swap: 3002364 total, 0 used, 3002364 free. 2212828 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1735 root 20 0 761264 62972 8696 R 27.5 2.0 0:16.45 bro

However when running broctrl running standalone on the same machine I see:

top - 05:34:44 up 8 min, 2 users, load average: 0.68, 0.60, 0.40
Tasks: 100 total, 3 running, 97 sleeping, 0 stopped, 0 zombie
%Cpu(s): 10.3 us, 33.7 sy, 3.2 ni, 52.1 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3082108 total, 2578976 used, 503132 free, 30604 buffers
KiB Swap: 3002364 total, 0 used, 3002364 free. 2216848 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2356 root 20 0 529220 56588 8624 R 24.8 1.8 0:04.44 bro
2358 root 25 5 168756 50788 2896 R 15.6 1.6 0:02.24 bro

I like brocontrol’s ease of use and auto-reports, but not at the cost of an additional bro process that eats %15 CPU usage. Any explanation for this? Thank you.

James

2

Even in standalone mode, BroControl currently will have Bro listen for remote connections as some functionality of BroControl depends on that. Bro will fork a process to do the listening which is the additional bro process. The communication between parent, child, and peers use somewhat suboptimal I/O loops that rely on small timeouts which can be the reason for the extra CPU usage. From what I understand, the reason for it being that way is historical (i.e. there were reasons for doing it that way on older systems). I don’t know of any way to workaround it at this time, but improving/fixing the underlying problem is on the roadmap.

- Jon

3

Thanks a bunch Jon...that's a great response that really helps my understanding.

James