High RAM usage when Layer Progress Gauge Enabled?

[sarf2k4]

Dashboard plugin v 1.15.2 octoprint v1.4.2 Raspberry Pi 3b+

Using windows 10 64bit with firefox 82.0 (64-bit)

Hi, I was trying to rectify my problem with octoprint having a very unusual RAM usage if left unattended can gobble up to 8-12gb of ram which is more than what I really have. Long story short, I identified two issues that may interfere with octoprint's performance; dashboard's Layer progress Gauge and another firefox plugin (temporarily solved).

Upon monitoring closely of ram usage, disabling Layer Progress Gauge only uses around 250-400mb of my ram, while enabling it, it skyrocketed from around 600-1,300mb, which almost quadrupled.

I only monitored this behavior from windows 10 task manager and I observed this behavior between enabling and disabling this feature at least 3 times.

Is this a normal behavior? I think it is abnormal to gobble such amount of data, unless this feature instructs the browser to also "cache the next whole layer" then compares the current gcode's progress to the "cached current layer".

[j7126]

The layer progress gauge gets its data from the gcode viewer tab in octoprint which loads and analyses the gcode that you are printing, meaning that having this gauge enabled should be equivalent to opening the gocde viewer tab. It is expected that this will create more ram usage.

The amount of ram usage that you are describing however seems unusual (unless you are printing a very large gcode file). Can you please send the gcode file that you are printing and also please test if simply opening the gcode viewer tab causes the same increase in ram?

[sarf2k4]

some print.txt

Here you go, I also noticed that the Display Layer Progress has the same thing which I enabled in browser's tab title by appending it when I was looking through the setting and monitors the browser's title. The ram usage are very small like non-existent compared to Layer Progress Gauge.

I only tested on virtual printer as it gives me much faster time to identify this kind of issues.

Instead of behaving like gcode viewer, can't you just somewhat "fetch" the current layer progress from Display Layer Progress plugin instead and this should be way lesser ram consumption than what it is now. I hope you don't get offended by the following; the way that you described Layer Progress Gauge's behavior it is somewhat having the Dashboard reading the gcode as well thus the requirement to have Display Layer Progress installed in my opinion is somewhat unnecessary.

P.S: I opened the stock gcode viewer ( i have cancel object and exclude region installed too), the ram usage spiked to around 800mb with all options below ticked, opening PrettyGcode section spiked to 1,000-1,200mb. Ram usage peaked at around 1,500mb and I go back to dashboard tab, for almost in a minute the ram usage down to around 1,200mb now and it hovers there.

I refreshed the tab, the ram usage peaked to almost 1,900mb then for about 20 seconds or so, down to around 1,200mb, then down to the basic ram usage which is around 250-500mb, I opened the gcode viewer again, let it load and everything, ram usage goes to 800-1,200mb.

I hope this information helps.

[j7126]

As far as I know, display layer progress does not tell you the progress of the current layer, so getting it from there is not possible (feel free to point it out if I am wrong https://github.com/OllisGit/OctoPrint-DisplayLayerProgress#events).

I have tested with the gcode file you provided, and as expected the ram usage is higher, however it is not as high as you have described, topping out at 460 mb.

I think you may have misunderstood exactly what I was saying, dashboard gets the layer progress from the gcode view that is already in octoprint, so having the layer progress enabled is in effect just viewing the gcode viewer and getting the info from there. Could you please open the gcode viewer tab and see if the ram usage issue occurs, so we can see if the excessive usage on your device is being caused by the gcode viewer tab or by the way that dashboard interacts with it.

I do agree with you that this guage should probably get its information from somewhere other than the gcode viewer, however as dlp does not provide this metric this will probably require additional custom gcode processing.

[j7126]

I just saw your edit, it seems like it is just due to the gcode viewer loading the gcode analysis, a solution to fix this issue in the future would be to instead of relying on the gcode viewer, to have dashboard do its own processing on the server side.

[sarf2k4]

I just noticed that it is the overall print progress either, sorry about that. viewing other tabs from the gcode viewer, the ram usage now sits at around 1,000mb, but everything pretty much still responsive. Can you inspect a behavior problem especially with another firefox addon maybe you can get a workaround with the problematic firefox addon?

Long story: I have ninja-cookie plugin installed from https://ninja-cookie.com/ also available via firefox addon page, days ago I had problem where firefox suddenly consumes up to around 6-12gb of ram if left unattended. This was because upon refreshing the octoprint dashboard page, there's something going on with the addon in "trying to do its magic" and it just doesn't stop there, the ram usage gradually increased. I tried with octoprint safe mode, the ram usage stayed around 400mb, while having dashboard on even without current layer progress gauge enabled, the ram usage gradually increased past 1.5gb and beyond, at this point, everything just unresponsive. The whole gradual ram usage increase is when there's a print job running.

[j7126]

layer progress processing will be done server side in v2

[charredchar]

layer progress processing will be done server side in v2

Just curious about this, what impact would calculating this server side have on a Pi running OctoPrint? I've been having a lot of issues running OctoPi with DisplayLayerProgress+Dashboard running in a Kiosked Chrome locally on the same Pi and worried demanding more from the Pi will make it unusable in this aspect. Or is calculating this server side such a small impact compared to calculating it in browser?

[j7126]

@charredchar the major difference is that the gcode viewer processes everything in real time, whereas the server side processing will be pre-processed, this means that it should have little performance impact during the print as the processing for the layer progress will be done when the file is uploaded and that pre processed metadata will be referenced during the print.

Additionally, the way it is currently implemented by depending on the gcode viewer causes the gcode viewer to always be running, and it does many other calculations and visualizes the gcode that impact performance on the client side.

[charredchar]

I see, thank you for explaining that! So actually, in the end it should be less of an impact for running on the same Pi as the server. My only other concern is I've noticed the timing being really off between OctoPrint's estimate and real print time, even with Time Genius, though less so with it.

[j7126]

I am closing this issue for now, as we are moving all discussion related to v2 to #249