Ticket #31 (closed Problem: Solved)

Opened 3 years ago

Last modified 2 years ago

Loading listen-clear causes CPU load to increase dramatically

Reported by: seth Owned by:
Priority: Normal Milestone:
Component: Bro Version: 1.5.2
Keywords: Cc:

Description (last modified by seth) (diff)

When running Bro with only the listen-clear script loaded...
The CPU load spikes on both the parent and child processes.

./src/bro listen-clear

The CPU load spikes on both the parent and child processes.

I attached the output of the debug.log file from running the above command with "-B main-loop".

Attachments

debug.log Download (94.6 KB) - added by seth 3 years ago.
debug.log from run with -Bmain-loop
remote-comms.diff Download (1.5 KB) - added by seth 3 years ago.
First attempt at a fix for the problem

Change History

Changed 3 years ago by seth

debug.log from run with -Bmain-loop

comment:1 Changed 3 years ago by seth

this is a test comment to test the bro-tracker mailing list

Changed 3 years ago by seth

First attempt at a fix for the problem

comment:2 Changed 3 years ago by seth

I just attached a diff that reduces the CPU load. From my initial tests, it looks like everything is working correctly but I really don't have a clue what effect an increased timeout on the parent's SocketComm? loop could have.

comment:3 follow-ups: ↓ 4 ↓ 5 Changed 3 years ago by robin

  • Status changed from new to seen

Two questions: (1) are both of the timeout changes needed to fix the problem; and (2) does changing the order inside if-conditions show any effect?

comment:4 in reply to: ↑ 3 Changed 3 years ago by seth

Replying to robin:

(1) are both of the timeout changes needed to fix the problem

Yes.

(2) does changing the order inside if-conditions show any effect?

Oops, those changes just sort of slipped in. That's unrelated. I was just playing around to see if there was any change by checking the straight boolean value first to short circuit the condition to not call the IsFillingUp?() method. It won't matter most of the time anyway because the IsFillingUp?() method would still be called regardless of the order of those conditions.

comment:5 in reply to: ↑ 3 Changed 2 years ago by seth

  • Description modified (diff)

Replying to robin:

Two questions: (1) are both of the timeout changes needed to fix the problem; and (2) does changing the order inside if-conditions show any effect?

comment:6 Changed 2 years ago by seth

  • Description modified (diff)

Replying to robin:

Two questions: (1) are both of the timeout changes needed to fix the problem; and (2) does changing the order inside if-conditions show any effect?

Was this issue addressed in a commit recently Robin? I noticed that you made a commit related to the timing code.

comment:7 Changed 2 years ago by robin

Partially. The values for the first timeout are changed along the lines of your patch but a bit less aggressively. But I haven't specifcally tested for the problem you report, which is also why the second part is not in there yet (the sleep makes me a bit nervous without further testing :)

comment:8 Changed 2 years ago by seth

  • Status changed from seen to closed
  • Resolution set to Solved

I would say that this has effectively been fixed. The CPU utilization on my laptop is around 0.5% when I only load listen-clear. I'm going to close this ticket but feel free to reopen it if you think there is more to this.

Note: See TracTickets for help on using tickets.