<div dir="ltr">The length of the test is 15 minutes.<div><br></div><div style>Doing another test to verify integrity shows some of the flows to be missing FIN packets. The traffic mirroring method I am using is not working properly. So this has nothing to do with Suricata, and setting the timeout for established flows to 60 seconds will temporarily resolve the problem. </div>
<div style><br></div><div style>This clarifies the issue, thanks!</div><div style><br></div><div style>Ted</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 4, 2013 at 12:33 AM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Sep 4, 2013 at 2:52 AM, Theodore Elhourani<br>
<<a href="mailto:theodore.elhourani@gmail.com">theodore.elhourani@gmail.com</a>> wrote:<br>
> I have a Suricata instance running on a machine with 2 CPUs, and 4GB of RAM.<br>
> Suricata is in workers mode and is using af-packet with 2 threads for<br>
> receive/detect.<br>
><br>
><br>
> I am generating http traffic using httperf. TCP connections are established.<br>
> In each connection, a total of 6 bursts, with 5 http requests in each, are<br>
> made every 1 second. The connection is then torn down.<br>
<br>
</div>What is the duration of the tests?<br>
Are the connections torn down properly?<br>
<div class="im"><br>
>The resulting bit<br>
> rate is 226Mbps (30k packets/sec). The total number of TCP connections in<br>
> the test is 80k.<br>
><br>
> With the "old values" below, suricata keeps on using more memory until all<br>
> 4GB are occupied. This is even though my connections are completing<br>
> correctly, with zero resets or session timeouts. In contrast, with the "new<br>
> values", it uses a maximum of 1500MB of memory. CPU utilization is always<br>
> below 90% in both cases. The tcp.reassembly_gap in both cases is around 2500<br>
> for the 80k connections, and there are no packet drops. Note that the stats<br>
> file reports roughly 39k tcp.sessions per thread. I am attaching the<br>
> build-info and stats for both old and new configs.<br>
><br>
> --------------------------------------------------------------------------------------------<br>
> The following is the only change made to the configuration:<br>
> tcp:<br>
>     new: 30<br>
>     established: 30 # old value: 3600, new value:30<br>
<br>
</div>The value of 3600 means that Suricata will wait 1 hr before it drops<br>
an established connection if it does not see a proper teardown of the<br>
tcp session.<br>
If there is no proper teardown  the memory consumption would<br>
accumulate overtime (until the timeout value is reached for that<br>
specific connection) unless more aggressive tcp timeout values are<br>
configured.<br>
<div class="HOEnZb"><div class="h5"><br>
>     closed: 30 # old value: 120, new value: 30<br>
>     emergency-new: 10<br>
>     emergency-established: 30 # old value: 300, new value: 30<br>
>     emergency-closed: 20<br>
> ----------------------------------------------------------------------------------------------<br>
><br>
> It appears suricata is not releasing memory for closed connections when the<br>
> "old values" are used.<br>
><br>
</div></div></blockquote></div><br></div>