Cura gets slower & becomes unusable after being open for any significant time - even in Cura 5.0!

[michaelpond08]

Application Version

4.13.4

Platform

Windows 10

Printer

Ultimaker 5

Reproduction steps

1. Open cura & use to send print to printer
2. Leave cura open while print is completed, in case print needs to be adjusted.
3. Return to cura to make adjustments or start another print (after a few hours)

Actual results

At this point, cura is so slow it cannot load a model or slice, and needs to be force closed via the task manager and rebooted.

Expected results

Cura should remain just as usable as when first opened

cura.log

Checklist of files to include

• [X] Log file
• [ ] Project file

Additional information & file uploads

Computer resource usage (RAM, CPU, etc) is abnormally high when cura becomes non-responsive.

[fvrmr]

Hi @michaelpond08 thank you for your report. Could you install the Extensive Support Logging plugin? And run this while you have Cura open and becomes slow. https://marketplace.ultimaker.com/app/cura/plugins/UltimakerPackages/ExtensiveSupportLogging After that share the zip file here.

[michaelpond08]

Thank you for the plugin. I've activated it, and just now experienced the slow-down problem. Please see the log file attached. I've also included a screen-shot of the task manager, in case that's useful to you. remote-support_22-03-15-15_59_07.zip .

[Ghostkeeper]

Ah, sorry. That archive contains only a log file, which you had already posted in the original post. That ExtensiveSupportLogging plug-in should be given with some instructions, really. It can measure the execution time of subroutines in Cura, but will only do so when activated. So to start measuring what it's working on (when Cura is slow), you have to activate it by going to Extensions -> Remote Support -> Start CPU Profiler. Then do a few things that are performing badly. Then deactivate it by going to Extensions -> Remote Support -> Stop CPU Profiler (or click the button in the message). Finally, save the remote support package.

The log itself doesn't give a whole lot of information. It seems Cura was not interacted with but kept running overnight from the 13th to the 15th. And after that a slice was started that is a bit interesting. It shows this in the log:

2022-03-15 13:34:02,527 - DEBUG - [MainThread] UM.Backend.Backend._createSocket [231]: Previous socket existed. Closing that first.
2022-03-15 13:34:10,035 - DEBUG - [MainThread] UM.Backend.Backend._logSocketState [188]: Socket state changed to Listening
2022-03-15 13:34:10,068 - INFO - [MainThread] UM.Backend.Backend.startEngine [90]: Started engine process: C:\Program Files\Ultimaker Cura 4.13.1\CuraEngine.exe

Closing the previous socket shouldn't take 8 seconds.

Considering socket traffic is commonly monitored by antivirus software, perhaps that could be causing this issue specifically on your computer (where it's not happening on others). But that would mean that it's only slow upon slicing, not when interacting with the rest of the interface.

[carnaue]

I have the same issue. My own observations - when closing Cura via the GUI after having it open full time for about a week it does not actually remove itself from memory. You need to force it closed from the task manager in Windows 11. Then you can open Cura again and its working fine. Right now its using like 360mb of memory (just forced it closed and restarted it) after some days of use it will be at about 2400mb of memory even with no models loaded at the time and closing Cura will not remove the memory allocation to Cura. Seems like it just takes up more and more memory until performance is effected and you must force restart it.

Windows 11 and printer is Ender 3 S1 - using the Octoprint addon to send prints directly to the printer.

[michaelpond08]

Hello,

I have run the cpu profiler, and attached the log file. Cura had been running in the background for a few weeks (honestly, I had forgotten that I left it open). When I tried to open the window again, nothing happened. In order to start the CPU profiler, I had to open a second instance of Cura and start it from there. During this whole process, Cura was utilizing 2.9GB of RAM, which seems excessive for this program, especially since a fresh instance of the program utilizes well under 1GB. remote-support_22-04-20-11_54_12.zip

[michaelpond08]

Just created another log. This time Cura was using 3.2GB of RAM, and took about 5 minutes to slice something fairly simple. Additionally, the "CPU profile in progress" bar hardly moved at all, which I believe points to the program being non-responsive overall. Any indication as to what is causing this? Also, in response to the earlier question, I do not have any antivirus running aside from Windows Defender.

remote-support_22-04-25-11_53_04.zip

[michaelpond08]

Any further insight on this issue? It's really quite frustrating, and I'd love to help get it fixed in the next release, which seems like it's set to release soon, as there is already a beta version available.

[michaelpond08]

We are now over 3 months past when this bug was first identified. I'd sure appreciate some sort of response to know if anything on this issue is being seen/considered by the software team. This seems like a significant issue that would be worth understanding and resolving before users (like myself) get too frustrated with the slicing software and choose to go elsewhere. Once again, this time with Cura 5.0, the software became unusable after being open for less than 24 hours. I have attached a remote/extended support log for anyone who cares to take a look. Again, there is no antivirus running except for Windows Defender. Task manager shows Cura utilizing 1.5GB of RAM.

remote-support_22-06-08-09_01_32.zip

[nallath]

We've seen the issue being reported, but we've not been able to reproduce it ourselves. We're also insanely behind on our issue backlog as currently don't have a dedicated community manager anymore.

I will discuss this with the team.

[nallath]

I've had a few peeks into your data. It seems to be somewhere in the local printer connections. Could you check if using the printer via the cloud fixes the issue?

[michaelpond08]

Thank you for getting back to me on this. I have experienced this issue regardless of whether I send it to a local printer or print via the cloud. More often than not, I am sending prints to the printer via the cloud. The performance issue is present even before sending the print to the printer. If Cura has been open for any significant amount of time, the RAM usage goes through the roof, and the program becomes very sluggish, even during the model prep/slicing stage of the process.

[nallath]

I currently suspect the automatic detection of printers in the offline network. You could also try if it becomes sluggish if you disable the UM3NetworkingPlugin in the marketplace (which will break the ability to send prints to the cloud / local). If it doesn't happen in that case, it would pretty much confirm my suspicions.

[fieldOfView]

I am fairly sure there's a memory leak in python-zeroconf 0.31. Also see https://github.com/fieldOfView/Cura-OctoPrintPlugin/issues/277, where I am trying to load the version of zeroconf that I include in the plugin instead of the one that comes with Cura.

[nallath]

I've added the info here to an already existing item on our backlog: CURA-8372

[StephWoodhouse]

I'm having a similar issue but specifically since we got two material stations (Issue mentioned above was one I submitted). I've been keeping track of the memory usage since I read a previous comment, but I also noticed the CPU usage increasing (the software was left untouched, with no files opened), results below:

7:45am - 293 MB, CPU 1.1% (Performance normal) 8:45am - 380 MB, CPU 6.1% (Dip in performance, difficult to use software) 12:45pm - 653 MB, CPU 11.7% (Totally unusable) 14:00pm - 717 MB, CPU 11.0% (Totally unusable)

Closing the software at this point is very difficult without the use of Task Manager, and once the software has been restarted, the performance returns to normal (before degrading over time again)

[michaelpond08]

I'm having a similar issue but specifically since we got two material stations (Issue mentioned above was one I submitted).

I failed to mention it when I first opened this issue, but the two printers I have on the network are:

Ultimaker 3 Extended Ultimaker S5 w/ material station & air handler

I didn't think the material station would have played into this issue, but it sounds like there are now 2 cases that have that in common. Just figured this would be another data point worth sharing.

[michaelpond08]

Another episode of unresponsive software this morning, after less than 24 hours of being opened. Cura was left open with a model loaded, after having sent that model to the S5 with material station. Went to modify a setting and start a new print this morning, and it was very sluggish. I started the CPU profiler and had it running during a re-slice. Cura was using ~2GB of ram at this point.

I plan to re-open the same model after restarting the software, and configuring Cura to work with/send the print to the Ultimaker 3 Extended instead, to see if the same behavior occurs.

remote-support_22-06-30-09_05_25.zip

[michaelpond08]

As I mentioned in my last post, I left Cura running with the Ultimaker 3 Extended as the active printer. It's been open since my last post (about 5 days), and the software is just as responsive as when it was first opened. This really seems like it's somehow linked to the Ultimaker S5 printer. Whether it is further linked to the Material station, I can't say, because my S5 has always been connected to a material station.

Any clues in this new information? New developments in trying to reproduce the issue?

[StephWoodhouse]

This is a bit of a summery of our experience, as far as I can see it lines up with your experiences.

• We've been running a UM3, UM3E and UMS5 for a few years with no issues, the latest Cura version used with this configuration was Cura 4.13. They were all linked together and connected to via the UMS5.

• We then upgraded our setup to be 2 x UMS5 with a material station each, the UM3E is currently being used by a separate team that hasn't reported any issues with the software. The same UMS5 was used to connect the 2 printers together.

• Still using Cura 4.13, we start experiencing the dips in performance with the UMS5 and material station setup. This then continues after upgrading to Cura 5.0. The same UMS5 was used to connect the 2 printers together.

As far as I can see from our experience, the only thing that could be causing this is the addition of the material station, unless there's something else I'm not considering?

I don't know if this is significant, but we get a considerable dip in performance within just 1 hour of having the software open, instead of the 24 hours you were reporting. Not sure if this is because we have 2 UMS5 + material stations, or something else entirely.

[michaelpond08]

Hello All,

It seemed like the ultimaker s5/material station firmware update before the latest one had fixed the issue, but the issue has come back. It seems to have come back at the same time as I updated the s5 and material station to the latest firmware, within the last week or so.

Just putting it out there as evidence that this issue still exists.

[nallath]

I've been trying to reproduce the slowdowns that are being reported, but I'm not able to do so.

I currently have 30 Ultimaker printers associated with my account (so all connected via the cloud), of which a number have material stations. Even if I drastically increase the update speed (from once per 10 seconds to once every 2 seconds), I'm unable to get a slowdown. A few things are different in my setup, as I'm running from source and on Linux, but I'm not convinced that those should really make a difference here.

I will keep it running for a bit longer to see if something pops up

[michaelpond08]

Just did another CPU profile with Cura mostly unresponsive. Took several minutes to slice a very simple part. RAM usage during the CPU profile was ~4.2GB. remote-support_22-09-01-09_28_15.zip

[nallath]

I see that you're connected via local connection. Could you see if you have the same issue if you connect it via the cloud only?

[michaelpond08]

I'm not quite sure how to go about that. The printers and my computer are connected to the same network. Would I need to connect the printers or the computer to a separate network in order to do this?

[nallath]

Don't use the "add printer by IP". Then make sure that you only use the printers that are added automatically when you log in.

[StephWoodhouse]

I've recently updated to the latest version of Cura (5.1.1) and it appears to stop the RAM leakage issue. However, I've noticed that opening new files will slowly increases the ram usage instead. This doesn't appear to have any significant effect on the performance after opening roughly 8 different files, and restarting the software will reset it to the starting usage. EDIT I've since left cura running and have started to see the same drop in performance, although at a slightly slower rate.

[StephWoodhouse]

I've now updated to the latest version of Cura (5.2.1) and the poor performance seems to have finally been resolved, I've had multiple instances of Cura open all day and haven't seen any significant increases to RAM usage. I've also tested on a different device and saw the same, no drops in performance.

[ful4n1t0c0sme]

Cura 5.2.1 Same problem. Blocks my PC if left open for 20hs aprox.

[fieldOfView]

When reporting "Same problem", it really helps to share some more information, like if you use the OctoPrint plugin or to an Ultimaker printer via the local connection. It is also helpful to share your Cura.log, which will tell us more about your setup.

[tpedry]

I am having this same problem of using Cura for several hours, opening and closing it. The slicing and importing models gets slower and slower until the program won't even fully open. I am on iMac 2017 with 64G of memory. Is Cura working on this problem that seems to be very old?

[me0262]

I'm encountering this problem on 5.4.0 Modern Linux AppImage on Gentoo Linux. After leaving it open for a time, I started to experience a full system slowdown (mouse moving insanely slow). I go to my tty1 console and check top, and see that Cura is using almost half of my 32GB memory (recorded at RES 10.8g).

Gentoo Linux AMD Ryzen 7800X3D, 32GB DDR5 Geforce GT1030 (active, nouveau), Geforce GTX 970 (IOMMU forwarded to VM)

OctoPi 1.0.0 build 2023.07.20.144556 - new camera stack / OctoPrint 1.9.2 connected over IP (hmm, when did that happen, thought it was octoprint.local) to: Powerspec 3D X (Flashforge Creator X / Makerbot 1 Dual clone, like FF Creator Pro with no bay covers)

[GrahamDyer]

Same issue: https://github.com/Ultimaker/Cura/issues/16477 Cura 5.4 using 10GB of RAM within 3 minutes.

[GrahamDyer]

Cura v5.6, 24GB RAM usage, 93% of 32GB Ram after 12 minutes! Drivers all up to date Repair install of Win 11 Ryzen 7 3700x MSI X570-A PRO

https://github.com/Ultimaker/Cura/assets/3287001/7ad91daa-ccf9-4757-bdd8-6108d242284f