As soon as I open the editor, the memory usage starts increasing.
Soon it hits around 50GB and then the whole system becomes sluggish; at this moment I know my work up to now is lost as saving does not work, nothing does; the screen goes black and I have to hold the PC’s power button to shut it down, and turn it on again.
I probably have about 10 or so minutes from opening the editor until the crash.
I have observed that this behaviour does not depend on anything I do; I can open the editor, do nothing, make coffee and come back to it already in double digit GBs of usage. (this means it’s not related to additively loaded scenes, entering/exiting playmode etc; the memory leaks we know about and tolerate as they’re slow and we can still work) - this one is not them. This one’s gross.
In Windows Task Manager, the details of the Unity.exe Process mention the names of what’s using the 12 or so threads Unity opens, and tells me that “Open Project” or “Package Manager” is the one using all the ram, but by this stage, “Open Project” should have already unloaded as the project is now already open. Nope. It holds onto the thread. The same situation is true if it’s “Package Manager” - the package manager hasn’t been opened, no new packages in or out, so why would it be hoovering up ram?
The project is a tiny 5 scene VR project (for Quest headsets, so all the textures are low, the models are low poly, there is no post processing)
I am unfortunately tied to this unity version as it’s what’s used on the project at work and I know I’ll accidentally push the wrong files if I have to start micromanaging commits. I don’t want to force everyone else in the office to upgrade
It also happens on a blank project, and I’ve checked the logs but they conveniently end before the crash and look fine up until they do; annoyingly the Windows Event Viewer captures nothing except the Kernel Power fault (from me holding down the button).
I haven’t got any debug stuff attached, I did have Jetbrains Rider attached (with a package) but that was removed during attempts to solve this problem.
Have you tried to use the Unity Memory Profiler package? (Memory Profiler | Memory Profiler | 1.1.3) It can take captures from the Editor, and has the ability compare captures too. You could take one capture just after starting the editor and another a few minutes later, then use the compare function to see what’s changed between the two captures?
(Also, you mention being tied to this version, but it might be useful to know if it happens for an empty project in a more recent version - that might help us narrow down a potential cause. Totally understand if you can’t do that, but it could help us figure it out!)
I will try it later but I’ve so far not been able to figure out how to run the profiler while idle (not in play mode) as this problem is very much a “open unity, wait, crash” affair, no other action is required other than to simply open a project.
I had thought that the culprit was Windows Defender, as it likes to do “real time scanning”, as when I turned this off (which can only be done temporarily) the memory usage dropped from the high 30s to around 6gbs.
Yesterday, however, it began again even with Defender Scanning off.
This also appears to be version agnostic, at least, agnostic to a 2022.3.X version.
To build on Pete’s comment: Taking a memory snapshot is different to using the Profiler Window (though if you want to use that, you can switch its target from Playmode to Editor to profile the frame by frame data while the Editor is idle outside of Playmode) and can even be done via an API call to MemoryProfiler.TakeSnapshot().
Importantly, you might want to copy those snapshots into an empty project without that issue to open and analyse them there without the Editor slowly keeping uptowards it’s inevitable OOM.
I’m experiencing a very similar issue, maybe even the same issue. I’m on a student team using 2022.3. We’re making a VR game targeting meta quest, low spec, no high poly assets or textures. When in the editor I just sit and watch as the ram usage increases before my very eyes, ultimately resulting in a lock up that requires the task manager to escape. When running in flatscreen mode the game can run, but if I attach a VR headset and try to run it instantly freezes.
I tried forking the project and opening it in unity 6. This made the game run at a higher framerate and seemed to reduce the memory increasing issue, but when trying to play the game in VR the lockup returned.
I was not having this issue a week ago, it just started on Tuesday
I have yet to do either of those things, finals season has started. I do have version control and I will go back to a prior version when I have the chance.
A couple other things of note worth mentioning:
I have 16 gigabytes of ram, and amd 7700 series card. 16 gigs of ram is a little on the low end now days
I am on a team with 4 other people, some of them have issues with performance but I have it much worse than them
Before I experienced the issue I updated my graphics drivers. I have since reverted my drivers and while that did improve performance it just changed the time to crash from 3 seconds to 10 minutes, and of course it still crashes when an HMD is plugged in
One of my teammates has started doing things with the shader graph in URP that wasn’t committed before tuesday, so it’s possible that could have lead to the problem
I’ll follow up once I’ve fetched an older version to see if the issue is present back then as well
Although it has nothing to do with the increase in memory even if he doesn’t play it, the Unity Editor’s memory grows infinitely and cannot be reduced, which is already a cancer
To keep this thread productive: Please help us by providing more context and take 2 memory snapshots with the Memory Profiler package while the Editor memory usage increases and compare them. If opening them is impossible to do in the project where the memory increase is happening, you can copy the snapshots from one project’s MemoryCaptures folder to that of an empty project to have more time to study these two snapshots in comparison mode.
The Editor shouldn’t just constantly increase its memory usage. That’s either a bug in Unity, some Editor tooling extension you are using or some script in your project. But without examining the increase with the Memory Profiler it is impossible to tell and help you.
Update: I was able to use version control to pull up an earlier build. Ram usage was still high but I didn’t see a growing memory usage over time. I have not been able to get a memory snapshot yet but that will be my next port of call
I’m back from the holdiays and I’m able to take a look with the memory profiler. On the current build of the game I’m just not able to run the memory profiler while my HMD is plugged in and VR is active.
It looks pretty normal both idling in editor and in play mode when steamVR is not active, however if I have steamVR active and a HMD plugged in the editor becomes completely unresponsive when clicking play, thus it is impossible to get a memory snapshot at that time as I can’t click the button to create one
UPDATE: It randomly started working? Here’s a memory snapshot of the game running in VR
I don’t know what changed. I updated the visual scripting package and installed the memory profiler, beyond that I changed nothing about the code, drivers, or software version on the system.
Sorry for not getting back to this thread after so long. I can confirm that updating our packages fixed the issue with memory usage climbing while the game wasn’t running.
As for memory usage spiking while the game was running… that was very much our fault.
The issue involved an expanding rope object that would allocate new segments up to infinity. Under normal circumstances this wasn’t impossible, but because my computer is lower spec than my teammates a lag spike at level load would cause the rope to shoot off to infinity and thus allocate infinite objects. We misdiagnosed it as an engine level issue. It is categorically user error
Fun sidenote: One of my early Unity projects had an elevator with a linked chain rope that turned chain links visible and invisble as the elevator moved. We then experienced an issue where parts of the level would become invisible, but still have it’s colliders on. I thought it was a culling issue for a while until I binary searched (deactivating half of the level, then the other half, then half of that…) until it dawned on me that this was down to the elevator chain logic having broken free of it’s assumed cage due to a math and logic error, turning the level geometry invisible
