On Tue, Jun 12, 2018 at 4:26 PM Robin Sommer wrote:
> One question about Broker's endpoint::advance_time(): that's locking
> on each call when in pcap mode, i.e., once per packet. Could we limit
> that to cases where something actually needs to be done? Quick idea:
> use an atomic<> for
On Tue, Jun 12, 2018 at 14:16 -0500, you wrote:
> This has lead to the fix/workaround at [1], now in master, which
Cool, that indeed solved it! It also helps significantly when data
stores *are* being used; that still takes about 2x the time, but
that's much less than before. Now I'm
On Mon, Jun 11, 2018 at 6:30 PM Robin Sommer wrote:
> Confirmed that I'm still seeing that difference even when using the
> options to turn the stores. Tried it on two different Fedora 28
> systems, with similar results.
I had previously tried on a Fedora 28 VM w/ 4 CPUs and didn't
reproduce
On Fri, Jun 08, 2018 at 10:47 -0700, I wrote:
> Ok, I'll dig around a bit more and also double-check that I didn't
> change any settings in the meantime.
Confirmed that I'm still seeing that difference even when using the
options to turn the stores. Tried it on two different Fedora 28
systems,
Ok, I'll dig around a bit more and also double-check that I didn't
change any settings in the meantime.
Robin
On Fri, Jun 08, 2018 at 12:40 -0500, you wrote:
> On Fri, Jun 8, 2018 at 12:16 PM Jon Siwek wrote:
>
> > Only thing I'm thinking is that your test system maybe
> > does a poorer job
On Fri, Jun 8, 2018 at 10:23 AM Robin Sommer wrote:
>
> > # zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
> > Known::use_host_store=F Known::use_service_store=F
> > Known::use_cert_store=F
>
> That indeed gets it way down, though still not back to the same level
> on my box:
On Thu, Jun 07, 2018 at 17:05 -0500, you wrote:
> Thanks, if you pull master changes [1] again there's likely some improvement.
Yeah, a little bit, not much though.
> # zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
> Known::use_host_store=F Known::use_service_store=F
>
On Thu, Jun 7, 2018 at 12:21 PM Robin Sommer wrote:
>
> Hmm, I'm still seeing much larger runtimes on that M57 trace using our
> test configuration, even with yesterday's change:
>
> ; Master, pre-Broker
> # zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
> 73.72user 7.90system
Hmm, I'm still seeing much larger runtimes on that M57 trace using our
test configuration, even with yesterday's change:
; Master, pre-Broker
# zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
73.72user 7.90system 1:06.53elapsed 122%CPU (0avgtext+0avgdata
199092maxresident)
;
On Wed, Jun 6, 2018 at 2:10 PM Azoff, Justin S wrote:
> I haven't noticed a huge difference on a real multi process cluster, at least
> not a 30x change, so this is odd that pcap processing is so much slower.
> Especially since broker should be completely disabled when pcap files are
> being
On Wed, Jun 6, 2018 at 12:01 PM McMullan, Tim wrote:
> Is the Bro development team still optimizing the Broker/Actor framework?
Yes, in the sense that optimizations will be done according to
feedback. No, in the sense that there was no one actively looking
into it at the moment you asked.
>
> On Jun 6, 2018, at 12:54 PM, McMullan, Tim wrote:
>
> We are running into performance issues (30x slower) since the Broker patch
> (fe7e1ee) –
>
> We have 40G connections tapped from our storage filers feeding multiple Bro
> instances which analyze specifically only NFS and SMB traffic;
12 matches
Mail list logo
