[Oisf-users] suricata memory leak?

[Peter Manev]

On Wed, Jan 23, 2019 at 3:30 PM Michael Stone <mstone at mathom.us> wrote:
>
> On Tue, Jan 22, 2019 at 11:14:23AM +0100, Peter Manev wrote:
> >On Mon, Jan 21, 2019 at 8:01 PM Michael Stone <mstone at mathom.us> wrote:
> >> Yes. On a positive note, I rebuilt with rust 1.31 and pushed that over
> >> the weekend, and the RSS on that sensor has remained constant since
> >> then. I'll see if that continues going forward.
> >>
> >
> >It will be good to confirm that observation if that is true for all
> >sensors actually? (if ti is due to Rust ver upgrade )
>
> I'm ready to declare success on this. I'll keep talking about the one
> sensor because the effect is so pronounced, but the general pattern is
> holding true across all of them. There's a nightly SMB traffic spike,
> during which suricata's memory consumption increases significantly.
> (But, the memory numbers in stats.log do not reflect this!) With the

The "memory" stats do not reflect it at all?
What about total packet counts or other app layer counts - is that
reflected there ?? (example - app_layer.flow.smb , app_layer.tx.smb )

> older version of rust, the memory consumption did not drop all the way
> back again after the nightly traffic spike, and eventually the machine
> would OOM. With rust 1.31, when the traffic spike ends the memory
> consumption returns to its original level, and the machine keeps
> running. So I'm going to speculate that in this case the memory is being
> consumed in the rust SMB parser. Nothing particularly jumps out at me in
> the rust changelog between 1.24 and 1.31 but there have been ongoing
> improvements over time. (In fact, the notes for 1.32 include "The
> default allocator has changed from jemalloc to the default allocator on
> your system." so that's another presumably big change to watch for.)

You have observed this with SMB related traffic only or other type too ?

Thank you for the feedback!

-- 
Regards,
Peter Manev