Re: [Bro-Dev] help Reading the backtrace

2017-01-20 Thread Robin Sommer
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

Re: [Bro-Dev] help Reading the backtrace

2017-01-19 Thread Aashish Sharma
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

Re: [Bro-Dev] help Reading the backtrace

2017-01-19 Thread Robin Sommer
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

Re: [Bro-Dev] help Reading the backtrace

2017-01-19 Thread Jan Grashöfer
> 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

Re: [Bro-Dev] help Reading the backtrace

2017-01-18 Thread Azoff, Justin S
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,

Re: [Bro-Dev] help Reading the backtrace

2017-01-18 Thread Aashish Sharma
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

Re: [Bro-Dev] help Reading the backtrace

2017-01-18 Thread Azoff, Justin S
> 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

Re: [Bro-Dev] help Reading the backtrace

2017-01-18 Thread Jan Grashöfer
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

[Bro-Dev] help Reading the backtrace

2017-01-18 Thread Aashish Sharma
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