# Version: 2.0-907 -- Bro manager memory exhaustion

**URL:** <https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385>\
**Category:** Zeek\
**Created:** [August 1, 2012, 8:00pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385 "2012-08-01T20:00:59Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tritium\_Cat](https://avatars.discourse-cdn.com/v4/letter/t/e8c25b/32.png) [@Tritium\_Cat](https://community.zeek.org/u/Tritium_Cat)\
**Post date:** [August 1, 2012, 8:00pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/1 "2012-08-01T20:00:59Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Scott\_Campbell](https://avatars.discourse-cdn.com/v4/letter/s/54ee81/32.png) [@Scott\_Campbell](https://community.zeek.org/u/Scott_Campbell)\
**Post date:** [August 1, 2012, 8:59pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/2 "2012-08-01T20:59:09Z")

</div>

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. 🙂

---

<div class="post-metadata">

**Author:** ![Martin\_Holste](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@Martin\_Holste](https://community.zeek.org/u/Martin_Holste)\
**Post date:** [August 1, 2012, 9:09pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/3 "2012-08-01T21:09:27Z")

</div>

> 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.

---

<div class="post-metadata">

**Author:** ![Tritium\_Cat](https://avatars.discourse-cdn.com/v4/letter/t/e8c25b/32.png) [@Tritium\_Cat](https://community.zeek.org/u/Tritium_Cat)\
**Post date:** [August 1, 2012, 9:31pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/4 "2012-08-01T21:31:46Z")

</div>

Here here. This configures the IXGBE card at boot.

#!/bin/sh

---

<div class="post-metadata">

**Author:** ![Tritium\_Cat](https://avatars.discourse-cdn.com/v4/letter/t/e8c25b/32.png) [@Tritium\_Cat](https://community.zeek.org/u/Tritium_Cat)\
**Post date:** [August 1, 2012, 9:58pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/5 "2012-08-01T21:58:00Z")

</div>

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](http://people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf)

–TC

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [August 2, 2012, 3:55pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/6 "2012-08-02T15:55:11Z")

</div>

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

Robin

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:40pm UTC](https://community.zeek.org/t/version-2-0-907-bro-manager-memory-exhaustion/2385/7 "2022-05-06T15:40:28Z")

</div>


