Memory issue

[olivierHa]

I think there is a memory leak with the upstream version of Livestatus.
LS broker module was stable around 1Go with my previous version (see performance issue, ie before the threading model) for more than 1 year, now it can increase up to 12Go and more ( I reloaded it at 12Go ...)

[mohierf]

We noticed the same problem with @ddurieux on an other module ... and there is also this issue shinken-monitoring/mod-webui#128

A more global memory leak problem in the new Shinken framework ?

[olivierHa]

Only the PID of the Livestatus module was eating memory.
I took an old livestatus revision (but with shinken fmw 2.4) to be sure.

2015-05-11 18:18 GMT+02:00 Frédéric MOHIER notifications@github.com:

We noticed the same problem with @ddurieux https://github.com/ddurieux
on an other module ... and there is also this issue
shinken-monitoring/mod-webui#128
shinken-monitoring/mod-webui#128

A more global memory leak problem in the new Shinken framework ?

—
Reply to this email directly or view it on GitHub
#63 (comment)
.

[gst]

@olivierHa :

I think there is a memory leak with the upstream version of Livestatus.

:D you mean since 1.4.2 ? (more precisely since fe3f7ad )

if yes then maybe the gc.collect() ought to be useful in a way or another (for that kind of problematic) !?? (while theoretically it shouldn't change anything, though..) :°@
but of course it ought not to be useful for perfs, we've seen that, given it's previous call frequency... (/o)
anyway : that's first has all to do with some specific(s) item(s) from the config you use, in fact, 'cause about all & everything, from the config perspective (but not only), is managed unconsistentlydifferently in the code, here, there, and overthere too ;)

first thing you can try : re-add gc.collect() somewhere in the code ! yeah :D ok but not at the same place than previously ;°)

can you say when occurs the increase of memory consumption in the process ? when you have a restart of arbiter, that's it ?? if yes, I hope so, then re-adding gc.collect() in the broker somewhere after when a new config is received maybe could help..

but I won't be able to help more for now guys..

[olivierHa]

@gst, yes I mean 1.4.2
ddurieux told me on IRC that he is tracking a memory leak too, so I am
waiting for his patch/feedback to see if our issues are linked.
Otherwise, I will dig to see when this memory leak is happening.

2015-05-12 21:13 GMT+02:00 Grégory Starck notifications@github.com:

@olivierHa https://github.com/olivierHa :

I think there is a memory leak with the upstream version of Livestatus.

:D you mean since 1.4.2 ? (more precisely since fe3f7ad
fe3f7ad
)

if yes then maybe the gc.collect() ought to be useful in a way or another
(for that kind of problematic) !?? (while theoretically it shouldn't
change anything, though..) :°@
but of course it ought not to be useful for perfs, we've seen that, given
it's previous call frequency... (/o)
anyway : that's first has all to do with some specific(s) item(s) from the
config you use, in fact, 'cause about all & everything, from the config
perspective (but not only), is managed unconsistentlydifferently in the
code, here, there, and overthere too ;)

first thing you can try : re-add gc.collect() somewhere in the code ! yeah
:D ok but not at the same place than previously ;°)

can you say when occurs the increase of memory consumption in the process
? when you have a restart of arbiter, that's it ?? if yes, I hope so, then
re-adding gc.collect() in the broker somewhere after when a new config is
received maybe could help..

but I won't be able to help more for now guys..

—
Reply to this email directly or view it on GitHub
#63 (comment)
.