Well that doesn't look great, but could be a lot worse. Hard to say without knowing what it looked like before the patch.
The fact that pending ever goes down at all is a good sign, but pending=0 is really the optimal state.
Mike, could you back out that patch and try my branch, topic/seth/remove-flare ?
.Seth
Hey guys
Fresh installation of bro 2.4.1, didn't modify scripts either
I'm experiencing similar issues, now I wanted to know, can we limit
the queue size (pending size)?
'Cause I don't care about packet losses
I already checked the help messages in bro, there's simply no such
option to configure, am I wrong?
This isn’t an issue with packet queueing. It’s unfortunately quite a bit deeper than that and is related to Bro existing communication mechanism and a problem with it that we fairly recently became aware of. We’re still digging into the solution for the problem.
.Seth
After 30 min things look better, I will let you know how the rest of it makes out after a bit.
Oct 23 12:09:52 manager child - - - info selects=100000 canwrites=97046 pending=0
Oct 23 12:11:54 manager child - - - info selects=200000 canwrites=97046 pending=0
Oct 23 12:14:04 manager child - - - info selects=300000 canwrites=97046 pending=0
Oct 23 12:14:43 manager child - - - info selects=400000 canwrites=97046 pending=0
Oct 23 12:15:20 manager child - - - info selects=500000 canwrites=97046 pending=0
Oct 23 12:15:54 manager child - - - info selects=600000 canwrites=97046 pending=0
Oct 23 12:16:38 manager child - - - info selects=700000 canwrites=97046 pending=0
Oct 23 12:17:41 manager child - - - info selects=800000 canwrites=97046 pending=0
Oct 23 12:19:03 manager child - - - info selects=900000 canwrites=97046 pending=0
Oct 23 12:20:46 manager child - - - info selects=1000000 canwrites=97046 pending=0
Oct 23 12:23:04 manager child - - - info selects=1100000 canwrites=97046 pending=0
Oct 23 12:25:10 manager child - - - info selects=1200000 canwrites=104987 pending=0
Oct 23 12:26:40 manager child - - - info selects=1300000 canwrites=104987 pending=0
Oct 23 12:28:13 manager child - - - info selects=1400000 canwrites=104987 pending=0
Oct 23 12:31:12 manager child - - - info selects=1600000 canwrites=110134 pending=0
Oct 23 12:32:24 manager child - - - info selects=1700000 canwrites=110134 pending=0
Oct 23 12:34:03 manager child - - - info selects=1800000 canwrites=110134 pending=0
Oct 23 12:35:12 manager child - - - info selects=1900000 canwrites=110134 pending=0
Oct 23 12:36:15 manager child - - - info selects=2000000 canwrites=110134 pending=0
Oct 23 12:37:31 manager child - - - info selects=2100000 canwrites=110134 pending=0
I have two Security Onion sensors running 2.4, one monitors a combination of 100M general office internet traffic + 10G network, the other monitors four 1G networks which includes a publicly available website and lots of syslog and SMTP traffic. I ran the default Security Onion configuration on both and noticed the sensor monitoring four 1G networks would run out of memory over the course of a few hours. I spent a day turning off various analyzers until I isolated it to the intel analyzer. Ever since I turned intel.log off for that sensor, it’s run great for weeks. I tried adding intel feeds (via CriticalStack) and using a blank intel file, with no luck. Simply having the intel analyzer on always resulted in memory loss over time. I’m guessing it has something to do with the type of traffic that particular sensor sees (more HTTP, syslog, and SMTP), but I’m not entirely sure.
Don’t know if it’s related, but just thought I’d share my experience with Bro memory issues.
Eric
Hey Eric,
How exactly did you turn off intel log? I tried to comment out this
line, but nothing changed on my sensor,
@load policy/frameworks/intel/seen
Am I wrong? I was following this link:
https://www.bro.org/sphinx/frameworks/intel.html
Hey Aaron,
I did it by commenting out “@load intel” in /opt/bro/share/bro/site/local.bro. Give that a try and see if it works for you.
Eric
Thanks Eric,
I tried that and it's not working for me ... I even commented out
every protocol analyser. memory usage still goes up, just slower in
time
Perhaps the amount of traffic is too much for bro ids. I'm gonna send
another email