[Bro] high cpu usage and strange select(2) behavior

[Stephane Chazelas]

2012-02-09 12:31:29 -0500, sridhar basam:
[...]
> IMO looping through select isn't an issue. On an idle/lightly loaded
> system, select is going to be the dominate usage of cpu but when you
> start seeing increased load, the rest of the system begins to pick up
> in usage with select taking a smaller and smaller portion of the CPU.
> Is it really an issue using 30% CPU on an otherwise idle system?
[...]

Thanks Sridhar for the feedback.

That's assuming a system where only bro is running.

Here, bro is running in a VM, and I've got other VMs running
there (with CPU overcommit) and other software running on that
VM (other IDS which also do offline deep inspection in the
background), so those CPU cycles wasted by bro are not available
to those other processes and to the other VMs. (and it's 60%
CPU, not 30).

But the reason I asked was because I thought it was a
configuration problem of mine, because I found it abnormal for
bro to use that much CPU when idle, and thought that could
explain the alerts about dropped packets where the other IDSes
are fine.

> About using nanosleep vs select,  i don't really see any difference in
> terms of what you want to achieve. In either case the process doing
> the select or nanosleep is going to be put to sleep till the timer
> expires so they both end up achieving the same thing. It isn't
> uncommon for one to use select/poll in that way to sleep.
[...]

OK, I agree that's a minor point, but why not use the right tool
for the job? it makes the code easier to read and saves a few
CPU cycles.

Cheers,
Stephane