[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