Hi, I’m experiencing a memory inflation issue in my Unity project on Windows builds.
When I run the project, memory usage slowly keeps increasing over time. I have a pooling system in the hierarchy that handles spawning/despawning effects and objects. At first I suspected pooled VFX or respawn logic, but even after removing all VFX and respawn systems, the memory still keeps growing.
What’s interesting is:
The issue happens both in the Unity Editor and in Windows builds.
The exact same project/code runs fine on macOS with stable memory usage and no visible leaks.
Garbage Collector does not seem to reclaim memory properly on Windows.
Memory usage continuously inflates even when gameplay activity is minimal.
I’m trying to understand whether this is likely:
a managed memory allocation issue,
a native/GPU memory leak,
a DirectX/Windows-specific issue,
or something related to Unity itself.
What would be the best way to isolate and debug this kind of platform-specific memory inflation issue?
Most likely it’s going to be a homemade leak. Common causes are using the .material property (clones the material) when it should have been .sharedMaterial. Or circular references. Don’t look too far, 98% chance the issue is all yours.
Since you are on 6.2 consider updating to the 6.3 LTS.
Unity uses custom allocators to requests large chunks of memory from the system, and keeps them available for your game. For this reason, it’s not necessarily an issue that memory doesn’t get freed. The allocators also work differently based on the platform.
As suggested, go through the article and start with the Memory profiler to see where that memory is going. Then you can use more advanced tools if needed, if you suspect it’s a memory leak.
Thanks for the reply. I fixed the issue by updating Unity to version 6.4. My game is supposed to use around 1 GB of memory on average, but it was starting at 1 GB and every action in the game kept inflating the memory usage. At one point, it consumed 60 GB out of my 64 GB RAM. Now everything is working correctly as expected.
One thing to note is that 6.4 is a tech release, not an LTS release. This means it has only a minimal support window until the next release, 6.5 arrives, which is usually about three months. Changes and fixes are also not backported to tech releases.
If your project is already in production or close to release, you may want to try version 6.3 instead and check whether the issue is fixed there as well. 6.3 is an LTS release, which means it will receive support and bug fixes for at least two years.
Using 6.4 means you will likely need to upgrade every few months: to 6.5, 6.6, and eventually 6.7, which will be the next LTS release. Of course, if your project is still early in development, continuously upgrading as new Unity versions are released is usually manageable. However, once you get closer to publishing your game, it is generally best to lock the project to the latest LTS version.
Yes and no.
Tech releases no longer exist. All current non-LTS versions, like 6.4 right now, are fully supported releases, which is why they’re also tagged as ‘recommended’ in the Hub (for new projects). That wasn’t the case with the old tech releases.
The only limitation is the support duration, which, similar to the former tech releases, lasts only until the next major release appears (e.g. 6.5).
Backporting means that a fix made in a newer version is also applied to older versions. Since their support windows end whenever a new major release is published, nothing gets backported to those releases. During their support phase, there is effectively nothing to backport because no newer versions exist yet for fixes to come from.
I’m only mentioning this because updating to a new major release that fixes an issue in your project, while also introducing another issue due to a new feature, can create a difficult situation that leaves you with no good options. The fix does not get backported to the previous major release, yet the new issue still affects your project. The discussions are full of topics describing exactly these kinds of problems, so use at your own risk.
With an LTS release, however, the fix will usually be applied without introducing the new issue, because new features are not adopted into LTS versions. Only fixes are backported to LTS releases, new features are not added.
Most bug fixes are implemented in the betas/alphas first and then backported. You can find many fixes appearing in the release notes for 6.6 (alpha), 6.5 (beta), 6.4 (supported), 6.3 (LTS), and 6.0 (LTS) at the same time.
You are right about that, but it doesn’t change the core meaning of my recommendation to the OP. For a project already released or near release, use LTS releases, or you risk ending up in a situation where one bug is fixed in the next version only to introduce a new bug due to a new feature.
For production projects, use only LTS releases, or you risk ending up in the same bad position as many others, as seen in various forum threads, caught between two versions that each contain different bugs.
