Federico Di Pierro

We are seeing the same on our test-infra cluster btw; Falco master images are now using glibc malloc (ie: not jemalloc and not mimalloc): Btw 1 thing to note is...

I mean, if thread table size is limited from Falco config, it means it will lose track of many processes; that means `proc.X` filters (and `fd` related ones) would probably...

Btw ~7hrs in, and the glibc allocator + very low limit of thread table size seems much more stable (and less memory hungry, as expected): Until this morning -> glibc...

Final outcome: even with glibc malloc AND limited thread table size, we still have some problems. I am now trying with glibc malloc AND main container plugin version, that contains...

I spotted a logic that was a bit flawed and addressed it: https://github.com/falcosecurity/libs/pull/2570 In my (local) tests, the memory seems more stable with the patch. We are going to bump...

Spolier: it does not :/ @nabokihms can you try to disable `syslog_output` in Falco config, if it is enabled? Basically, i noticed that the pod that show steadily increasing memory,...

> @nabokihms can you try to disable syslog_output in Falco config, if it is enabled? I am trying the same in our test-infra cluster. Let's see if that makes any...

Unfortunately no luck here too Will try to find something else :) EDIT: here you can see the 2 stable lines are from the pods that are not receiving events;...

Update: it might be related to the container plugin, possibly due to some issue with golang worker in the plugin and cgo; eg: https://github.com/golang/go/issues/71150

https://github.com/containerd/containerd/pull/12465 will eventually allow us to bump the deps.