> https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=expire#id-table_expire_delay).
This is very helpful. I have been testing out table_expire_delay but somehow wasn't looking at table_incremental_step I'll test out a million expires while teaking table_incremental_step to see what the limits are here. 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 processing ? Aashish On Thu, Jan 19, 2017 at 10:55:45AM +0100, Jan Grashöfer wrote: > > 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 so > > much iteration. > > If I am not mistaken, tables are basically dictionaries (with the > exception of subnet-indexed tables). The iterations should be related to > how expiration works: As soon as the timer fires, the table is looped > looking for expired entries. To prevent blocking in case of too many > expired entries that have to be handled, only > <table_incremental_step>-number of entries are processed, following a > delay of <table_expire_delay>. Adjusting this parameters might help (see > https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=expire#id-table_expire_delay). > > Jan _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
