Search Unity

Unity Editor memory usage grows without bounds

Discussion in 'Editor & General Support' started by pw_aowen, Oct 5, 2021.

  1. pw_aowen

    pw_aowen

    Joined:
    Nov 30, 2018
    Posts:
    12
    Hi all,

    We recently upgraded our project to Unity 2020.3.19f1 (upgraded from Unity 2018.4.28f1). Many of our developers are observing Unity Editor's memory usage grow at a rate ~10MB/sec when sitting on our main menu (as reported by Windows Task Manager). Some developers have reported it growing to 20GB before they're forced to close Unity and re-open. Our main menu isn't doing anything complicated, it's just playing some particles & animations.

    During our troubleshooting we've observed the following
    1) Disabling all Particle Systems from the Hierarchy (t: ParticleSystem) stops the issue
    2) On some developer machines, opening the Profiler (Window > Analysis > Profiler) stops the issue. This is not ideal, since we want the issue to be reproducing with the Profiler running..
    3) Standalone builds (PC) does not reproduce the issue.

    Does anyone have any insight on the above? Here are some guiding questions
    1) Any known "particle system memory leak" related issues or pitfalls we should know?
    2) Any idea why opening the Profiler window would stop the issue?

    Any other guidance, help, or tips are welcome!
     
    Last edited: Oct 6, 2021
    pw_aowen, Oct 5, 2021
    #1
    solkyoshiro likes this.

  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,460
    Hi there,
    I'm not concretely aware of any and couldn't find any with a quick search of the bug database, but that doesn't mean there isn't one. Still might be worth reporting one if further memory analysis doesn't point at something within your project.

    I believe it might be triggering Resources.UnloadUnusedAssets when it notices that it's running out of memory.

    Editor memory usage behaves differently than a player. It could be some editor only allocations that get leaked.

    To avoid the Profiler affecting the results and to be able to narrow it down a bit, you could instead attach the Memory Profiler package, make 2 captures while the memory grows and open both of them in the compare view to see if you can get any details on where that memory growth is occurring.

    Also, we have this, now slightly outdated, workflow guide to analyzing memory leaks with the tool, that might be helpful.
     
    MartinTilo, Oct 6, 2021
    #2
    pw_aowen likes this.

  3. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,460
    Correction, that bug was fixed and the backport landed on 2020.3.19f1 so that shouldn't be it.
     
    MartinTilo, Oct 6, 2021
    #3

  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,460
    If you have any more info to narrow down under which circumstances and on what kind of machines opening the Profiler does or does not impact this, we can have another check that the bug is properly fixed or what else might be causing the change in behavior. Interesting points to look out for could be:
    • Total RAM in the machine
    • Total RAM available to Unity
    • Number of retained profiler frames (Preferences/Profiler/Frame Count)
    • Deep Profiling/Call Stack recordin on or off
    • Which Profiler Modules are actively recording (aka have charts within the Profiler window)
     
    MartinTilo, Oct 6, 2021
    #4

  5. pw_aowen

    pw_aowen

    Joined:
    Nov 30, 2018
    Posts:
    12
    Hi Martin, thanks for the recommendation.

    I'm still analyzing the results, here is a screenshot of a comparison. The memory usage grew by ~670MB in 70 seconds. If I'm reading the break down correctly, it's something like

    ~150MB Virtual Machine
    ~130MB Graphics & Graphics Driver
    ~330MB Other

    I will drill into the tool further...I'm thinking "Objects and Allocations" tab, probably "All Native Objects" since I figure "All Managed Objects" is for Managed Memory's Objects.

    Do you have any insight into the "Other" section of memory? At 330MB, I'm squinting at it the most.

    upload_2021-10-6_12-8-9.png
     
    pw_aowen, Oct 6, 2021
    #5

  6. pw_aowen

    pw_aowen

    Joined:
    Nov 30, 2018
    Posts:
    12
    Hey, new information on this front

    My colleague and I reproduced the memory leak as described. I opened up my Profiler and the leak stopped. He opened up his and it did not stop. I had only the Memory Module up, while he had all the defaults up. He unchecked all of them except Memory, and then the leak stopped on his machine. After some experimenting, I'd summarize the results as:

    Having UI Details Module enabled on the Profiler causes the memory leak to occur. Unchecking UI Details stops the leak.

    In answer to other info you requested:
    We both had these settings
    - Frame Count: 300
    - "Show Stats for 'current frame'": unchecked
    - Default recording state: Disabled
    - Default editor target mode: Playmode
    - Deep Profiling: off
    - Call Stack: off

    It seems strange that even though our default recording state was disabled, the Profiler was affecting memory in this way. We had both set it to Disabled earlier this week, because we were like "doesn't profiling affect performance? let's turn that off unless we need it".
     
    pw_aowen, Oct 6, 2021
    #6

  7. pw_aowen

    pw_aowen

    Joined:
    Nov 30, 2018
    Posts:
    12
    Hi Martin,

    We're found the issue! It was a combination of things, and they were solely on our end.

    It turns out we were setting Profiler.enabled to true in code when Play mode was entered. This was problematic, because some of our 3rd party libraries were hooking into custom samples with Profiler.BeginSample. The most prevalent usage was a library that was used for particle effects! (explaining why disabling all particle effects resolved the issue).

    The result was that the profiler was secretly collecting data in Play mode, and eating lots of memory! Removing Profiler.enabled resolved the issue.

    An open question is why this behavior appeared in Unity 2020, but not Unity 2018, but that's not very important, imo. I am chalking it up to "Profiler.enable will enable more things than it did before".
     
    pw_aowen, Oct 7, 2021
    #7

  8. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,460
    Hey again,
    Sorry for the longer silence. I'm glad you found a solution though. I'm still not entirely sure I understand the underlying issue that caused this but I can try to illuminate some parts at least:


    That's basically the Native (CPU side) Memory Heap, minus Audio and Profiler. So all the Assets, Native Objects and Native subsystems.

    If the memory grew due to the Profiler running in the background, I would have expected the Profiler memory to grow though. Then again, the Profiler Memory sits in it's own Allocator with it's own memory pool and should technically cap out at some point, meaning older frame info is dropped... But I guess if you have some side effects from profiling in 3rd party code, that would be a different story.


    In 2018.3 we introduced Profiler.SetAreaEnabled and the ability to turn of specific Profiler Modules to not incur the overhead of collecting and storing their stats. I think we then at some point might have fixed/changed how the enabled state for the modules is synced between the Profiler Window and a running Player, and similarly likely change how Profiler.enable and ProfilerDriver.enable and how the Profiler Window's recording state gets synced as well so, likely somewhere in those changes lies the origin of this popping up as you upgraded to 2020.
     
    MartinTilo, Oct 14, 2021
    #8