Version: 2.0-907 -- Bro manager memory exhaustion

You might be right. I had considered disk I/O and ran the manager on a decent raid-10 array (the elsa server), disk i/o did not appear to be the problem so much as CPU and memory. That observation carried over to development builds with a threaded manager, but at an accelerated rate; right now I’m watching the disk I/O under threshold and the manager is consuming 100M of memory per second until memory exhaustion.

My configuration is default with Conn::Log turned off. I’m still trying to obtain an idea of the performance baseline before adding additional scripts.

For my current setup it seems to work best if I segment the cluster so I’ll continue with that approach.

–TC

I have noticed that there seems to be a large volume of "soft"
information for high performance bro installations. This is
particularly true with PF_RING/DNA/libzero configuration and use.
Finding nice simple examples are also a bit scarce.

My proposal to address this is as follows: For anybody willing to
document this info - something as simple as a cut and paste of the
PF_RING/ixgbe startup configs and the node.cfg - I will purchase a
beer*. We will put this info up on the Bro web site for the
edification of those staring into the abyss of 10 (or 100!) G.

That is it. This project is personal and not funded or supported by
ICSI or anybody else for that matter. Can you imagine the IRB?

cheers!
scott

* Till I run out of money dedicated to the Bro documentation liquidity
fund. :slight_smile:

You might be right. I had considered disk I/O and ran the manager on a
decent raid-10 array (the elsa server), disk i/o did not appear to be the
problem so much as CPU and memory. That observation carried over to
development builds with a threaded manager, but at an accelerated rate;
right now I'm watching the disk I/O under threshold and the manager is
consuming 100M of memory per second until memory exhaustion.

How much I/O from the manager have you seen thus far? I'm not yet
convinced that writing raw text files is the bottleneck. When you
think about writing raw pcap, it's orders of magnitude more MB/sec to
disk than logging.

Here here. This configures the IXGBE card at boot.

#!/bin/sh

The highest I’ve seen so far is 443 MB/s with waves of activity between 80 - 390 MB/s. That’s all within a 3 or 4 minute window of time before all the memory is near exhaustion. (45-50G for the manager).

I’m using the following to help profile the system:
people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf

–TC

This would be great indeed! And thanks for offering the "funding". :slight_smile:

Robin