[Oisf-users] suricata memory leak?
Michael Stone
mstone at mathom.us
Wed Jan 23 14:30:23 UTC 2019
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
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.)
More information about the Oisf-users
mailing list