On Thu, Jan 19, 2017 at 17:54 -0800, you wrote:
> -> pthread_cond_timedwait(_data[read_ptr], [read_ptr],
> );
Just be sure: are you sure this is the troublesome spot? I'm asking
because this is likely running inside a logging thread, and expected
to block frequently if there's
SO this doesn't (at the moment) seem to be related to table expiration. My
table is maintained on manager and expire_func only runs on manager.
But, I see 'a' worker stall with 99-100% CPU for a good while while all other
workers go down to 5-6% CPU. conn.log continues to grow though
GDB
On Thu, Jan 19, 2017 at 09:44 -0800, you wrote:
> Still, to clearify, there might be a possibility that because at
> present table_incremental_step=5000, somehow expiring >> 5000 entries
> continiously every moment might cause cause Queue to deadlock
> resulting in BRO to stop packets
> But I also wonder what you are doing that is triggering
> Dictionary9NextEntryERP7HashKeyRP10IterCookiei
>
> which would be
>
> void* Dictionary::NextEntry(HashKey*& h, IterCookie*& cookie, int
> return_hash) const
>
> Tables should be fine, but I wonder what you're doing that is triggering
Yeah.. lots of expires may have something to do with it, your traceback shows
TableEntryVal16ExpireAccessTimeEv
But I also wonder what you are doing that is triggering
Dictionary9NextEntryERP7HashKeyRP10IterCookiei
which would be
void* Dictionary::NextEntry(HashKey*& h, IterCookie*& cookie,
Yes, I have been making heavy use of tables ( think a million entries a day and
million expires a day)
Let me figure out a way to upload the scripts on github or send them yours and
justin's way otherwise.
Strangely this code kept running fine for last month and reasonably stable. I
am not
> On Jan 18, 2017, at 12:29 PM, Aashish Sharma wrote:
>
> So I am running a new detection package
It was stable before you added the new scripts? Are the new scripts publicly
available?
--
- Justin Azoff
___
bro-dev mailing
Hi Aashish,
> So I am running a new detection package and everything seemed right but
> somehow since yesterday each worker is running at 5.7% to 6.3% CPU and not
> generating logs.
my guess would be that the script makes (heavy) use of tables and table
expiration, right? Can you share the
So I am running a new detection package and everything seemed right but somehow
since yesterday each worker is running at 5.7% to 6.3% CPU and not generating
logs.
The backtrace shows the following and how much (%) CPU is spending on what
functions.
Can someone help me read why might BRO