I have a huge react app which causes very heavy memory usage in IE11, it will eventually lock up. I am testing memory usage in IE11 using the memory tab in the developer tools. It is showing increases in memory for every single page refresh. Using methods like window.CollectGarbage() do nothing at all, memory usage stays the same.
Now what really stumps me is that I created a blank HTML page with no CSS, no JS and watched the memory tab when I refreshed the page over and over. The memory started at about 80MB and got to over 200MB before I got bored of clicking refresh. How can this be? This seems to suggest its just the browser itself and it will eventually use up all of a systems RAM not matter what you do?...
Is this true? Is there a way to have a SPA in IE11 that can be used all day without issue? Any way to reset the RAM usage besides launching a new window?
Related
I am debugging a large node.js app that crashes very infrequently with an out of memory error.
Monitoring the process with OS tools does not show any worrisome trend in rss over long periods of time, but as soon as I attach either Chrome Inspector for Node.js or the VSCode JS debugger, I see memory going up steeply and fairly constantly. Many of the leaked objects seem to be under system, but the rss size increase seems to not be covered by the size of the objects in the heap. I see rss > 1GB, yet the heap only accounts for tens of MB, not 600+ MB increase in rss.
When I detach the debugger the rss goes back to almost the preattach state.
Also, a strange behavior of this app is that under single threaded perpetual load (sending continuously a new request as soon as one was serviced) speed is rather inconsistent. Identical requests are handled fast for a few seconds, then comes a minute of lower CPU usage and extreme slowness and the cycle repeats itself.
When I try to profile the app with Chrome Inspector, node.js crashes promptly.
I stubbed out much of the application. Now the app no longer crashes when profiled, but the debugger induced leak persists.
The retention tree looks like this:
[13]in(GC roots)#3
107 / DevTools console in (Global handles) #29
map in Object #381033
back_pointer in system / Map #382907
back_pointer in system / Map #387465
back_pointer in system / Map #387463
back_pointer in system / Map#387461
...
many long chains like this.
Looking at the Object in this chain, it looks like an HTTP socket
I am new to node.js anyone has any hints as to where to look for problems?
I have a Node app using express (rest api).
The thing works nicely except that it breaks if it keeps running too long.
By monitoring the memory, I noticed that the footprint goes up with every page reload/query sent.
Even after upping the memory to 8gb, I still finally end up with:
Reached heap limit Allocation failed - JavaScript heap out of memory
I googled a bit and tried adding --inspect and then looked at the chrome devtools, but I can't make sense of it. It shows the whole transpiled (ts->js) webpack bundle as a string multiple times.
Can't share the source code but would appreciate any general pointers what to look out for.
Background
I have a relatively simple node js application (essentially just expressjs + mongoose). It is currently running in production on an Ubuntu Server and serves about 20,000 page views per day.
Initially the application was running on a machine with 512 MB memory. Upon noticing that the server would essentially crash every so often I suspected that the application might be running out of memory, which was the case.
I have since moved the application to a server with 1 GB of memory. I have been monitoring the application and within a few minutes the application tends to reach about 200-250 MB of memory usage. Over longer periods of time (say 10+ hours) it seems that the amount keeps growing very slowly (I'm still investigating that).
I have been since been trying to figure out what is consuming the memory. I have been going through my code and have not found any obvious memory leaks (for example unclosed db connections and such).
Tests
I have implemented a handy heapdump function using node-heapdump and I have now enabled --expore-gc to be able to manually trigger garbage collection. From time to time I try triggering a manual GC to see what happens with the memory usage, but it seems to have no effect whatsoever.
I have also tried analysing heapdumps from time to time - but I'm not sure if what I'm seeing is normal or not. I do find it slightly suspicious that there is one entry with 93% of the retained size - but it just points to "builtins" (not really sure what the signifies).
Upon inspecting the 2nd highest retained size (Buffer) I can see that it links back to the same "builtins" via a setTimeout function in some Native Code. I suspect it is cache or https related (_cache, slabBuffer, tls).
Questions
Does this look normal for a Node JS application?
Is anyone able to draw any sort of conclusion from this?
What exactly is "builtins" (does it refer to builtin js types)?
I've got a Pyramid view that's misbehaving in an interesting way. What the view does is grab a pretty complex object hierarchy from a file (using pickle), does a little processing, then renders an html form. Nice and simple.
Setup:
I'm running Ubuntu 12.04 64bit, Python3.2, Pyramid 1.3.3, SQLAlchemy 0.7.8 and using the standard waitress server.
Symptoms
I was having some efficiency issues so used system monitor to try to see what was up and found that while pyramid is doing its processing and suchlike for the view I described my ram usage rose steadily. As the html form was displayed in my browser the ram usage leveled off but didn't fall. Reloading the view caused the ram usage to grow steadily from where it left off. If I keep doing this all my ram is used up and everything grinds to a halt.
If I kill the server then the ram usage drops back down immediately.
Question
What's going on? It's obvious that memory isn't being released between view renderings, but why is this happening? And how can I make it stop? I even tried calling del on stuff before returning from the view and nothing changed.
Pyramid's debug toolbar keeps objects alive. Deactivating it fixes most memory leak problems. The leak that was the cause of my searching for errors in Pyramid doesn't seem to be a problem with Pyramid at all
I've written an app which is handling videos. As we know, video processing takes a huge amount of memory while dealing with HD resolution. My App always seemed to crash. But actually I am 100% sure, that there is no memory leak in my code. Instruments is showing no leak.
At the beginning I am startin up one OpenGLES view and the video engine. For a very short time the memory consumption is high, but falling down to normal level after the initializations are done. I am always getting memory warnings during this period. Normally this is no problem. But if I have a lot of apps in suspended mode running, the App seems to be crashing. Watching into the crash log and using the debugger shows up, that I am only running out of memory.
My customers are flooding my support mail with "app is crashing" mails. But I do know, that they have too much Apps running in the background, so there is no memory left to go. I think it's bad style programing saying the customer that he has to close Background tasks before running the app.
According to this post this is a common problem.
My question is: Is it possible to tell the OS that one needs a lot of memory so the OS should terminate some suspended Apps? This memory stuff makes me crazy, because it's no bug I could fix.
No. It is not possible to affect anything outside of your sandbox without API calls. None exist for affecting other processes in the public API.
Have you tried to minimize your memory usage? In my experience once a memory warning it thrown apps can be more likely to have problems once they are in the background, even when memory usages drops.
If you are using OpenGLES and textures, if you haven't already compress your textures. What is the specific cause of your memory allocation spike?