search

fdietz / team_dashboard

Visualize your team's metrics all in one place.
http://fdietz.github.com/team_dashboard/
855 stars 141 forks source link

Memory Leak #12

Closed luxflux closed 12 years ago

luxflux commented 12 years ago

After running maybe 3 hours, the chromium process of team_dashboard (develeopment environment) uses about 1,5Gb RAM (chrome://memory-redirect). I'm using 2 Counter and 2 Graph widgets. Each of them updates in a 10 second interval.

I don't know where the problem lies. I'll check now with firefox to see wether it is browser specific or not. Do you experience also such a memory usage?

fdietz commented 12 years ago

Hi Raffael,

I've debugged this already a while ago but didn't have the time to investigate further here.

Using the Chrome Tools I was able to track down a problem in the rickshaw.js graph library or our usage of this library. For each graph widget update (10 second interval) the whole graph is currently thrown away and rendered again. Each rendering adds 2 new events and a couple of DOM elements, which are never cleaned up.

You can find a comment in graph.js line #117. If you disable the hover details for the graph these 2 events are gone.

Still this doesn't solve the increase of DOM elements.

Ideally, we would simply directly tell rickshaw.js to redraw the graph based on new data instead of recreating the whole graph init/rendering again. I have some time today to look into this, maybe there's a possibility for a quick fix here!

Kind regards, -Frederik

On Sun, Aug 19, 2012 at 2:27 PM, Raffael Schmid notifications@github.comwrote:

After running maybe 3 hours, the chromium process of team_dashboard (develeopment environment) uses about 1,5Gb RAM (chrome://memory-redirect). I'm using 2 Counter and 2 Graph widgets. Each of them updates in a 10 second interval.

I don't know where the problem lies. I'll check now with firefox to see wether it is browser specific or not. Do you experience also such a memory usage?

— Reply to this email directly or view it on GitHubhttps://github.com/fdietz/team_dashboard/issues/12.

fdietz commented 12 years ago

Hi again,

think I've fixed it: https://github.com/fdietz/team_dashboard/commit/a69fa6197f3ab17a5d6d5e59bad118888f8a6aeb

Give it a try please!

luxflux commented 12 years ago

It's a lot better. It increased now over night from 166Mb to 240Mb. So the leak is not that huge anymore but still not fixed. If you want to run this dashboard on a big screen 7x24 you will have problems after some days...

fdietz commented 12 years ago

Hi again! I guess this is due to the fact that the dom elements created by the graph are not cleaned up correctly when updating. Have to look some more into the rickshaw.js implementation to check how this could be done cleanly.

On Mon, Aug 20, 2012 at 8:33 AM, Raffael Schmid notifications@github.comwrote:

It's a lot better. It increased now over night from 166Mb to 240Mb. So the leak is not that huge anymore but still not fixed. If you want to run this dashboard on a big screen 7x24 you will have problems after some days...

— Reply to this email directly or view it on GitHubhttps://github.com/fdietz/team_dashboard/issues/12#issuecomment-7861751.

fdietz commented 12 years ago

I've got a silly fix for now. I simply refresh the dashboard page once per hour using a javascript timer. That way memory leaking widgets won't be an issue. It will take some more time to fix all the leaks though.

One strategy I haven't even started implementing will be to really only update the changed parts in a widget instead of rendering it again. So, there lots of room to optimise this further.