The system is running out of memory. Please close applications to free memory or free up space on th
After a couple of times running the app in Oculus Link from the Editor 2020.2 I get this memory message: The system is running out of memory. Please close applications to free memory or free up space on the partition where the pagefile is located. Used memory (physical and paged): 94% (30828MB of 32724MB). Discarding profiler frames data. If I run the app without Oculus Link, I don't get this error. I had disabled the Virtual Memory from Windows. Any ideas why this happens?1.8KViews0likes0CommentsWhere is my RAM? Unity app on Oculus GO non-deterministic crashing with < 1gb memory used!
Been at this for a couple weeks now, so I need help. I have a relatively large app with many features, and recently it started exhibiting crashes, mainly during a new scene load, which made it terrible to track down. I eventually figured out were due to out-of-memory issues. I had no logs saying this, but doing an adb bugreport eventually showed the culprit as lowmemorykiller ending the process abruptly. So using Unity's great profiling tools, I was able to get my RAM consumption down from about 2gb to under 1gb. Crashes seemingly abated. Then I went on with other optimizations, including switching from GLES2 to GLES3+Single Pass Rendering. Now the crashes are coming back! I'm not using any more memory, except possibly for GLES3 itself - the profiler shows 1.02gb in use, 0.76 for unity and 270mb for "GfxDriver". However, I was previously able to have 2gb in memory before crashes before, on GLES2, so why would I crash now at ~1gb on GLES3? Further, the crashes are not consistent - sometimes I can play everything fine with no crashes, other times not. Sometimes, simply connecting to the Unity profiler pushes me over the edge to a crash, further complicating my debugging process. If I'm interpreting things correctly, the profiler says (right before the crash) that I'm using 1.02gb out of "reserved" 1.05gb, and that 2.40gb "total system memory usage" - so what is using the extra 1.4gb? Is there any better way I can isolate the specific causes of the issue? I really can't do much more to manage my RAM usage. Half of it is out of my control - 270mb on the graphics driver, and 200mb for the eye render textures - and it just feels like every time I lower my memory usage a bit, the point where I get a crash becomes lower to compensate. If I can't get an answer I'll just have to go back to the inexplicably working GLES2, and lose single-pass rendering, but that will lead to degraded user experience, so please send any suggestions! Thanks2.2KViews2likes4CommentsMemory crash question, galaxy s7 gear vr, lots of textures
My gear vr application is crashing due to running out of memory. I know I'm using a lot, but I'm running on a Galaxy S7 with 4 Gigs of ram, so I was surprised to see my memory usage was below a gig. I'm wondering if it's an issue of allocated memory too fast, and not the total size. I can load and unload to address the issue, but would prefer to keep the textures ready. Here's the memory info from the profiler right before it crashes. Unity 5.4.1, android 6.0.1.476Views0likes0CommentsFYI - Memory Leak in Network Animator
Hey Fellow Devs; Been profiling memory, draw calls and etc. After eliminating/hitting most of my bigger leaks, I noticed a pretty constant leak coming from the Network Animator object. Now, if you are making a network game, this is kind of important, because it *will* eventually trigger a GC that'll definitely give you a FPS hiccup. It's only ~2-4K every few frames, but it adds up over a minute or two. Anyway, given that there are other known issues with Network Animator, I've basically trashed it from my project. Best work around for keeping animations "in sync" with each other is to do the following: 1. Create a SyncVar(hook="InputUpdatedX") for both your X/Y inputs for movement if you have any animations tied to these. 2. Create a "RpcTriggerSync" to keep any trigger events up to date. These didn't sync with Network Animator any. 3. Repeat step one for any other state transition types. In a nutshell, that should keep your players sync'd up, it's a bit more network traffic (actually lower than using network animator) and it keeps your players animations roughly syncronized without the pesky behavior leak. Cheers, T683Views2likes0Comments