{"id":1165,"date":"2015-11-18T03:34:44","date_gmt":"2015-11-17T21:34:44","guid":{"rendered":"http:\/\/promincproductions.com\/blog\/?p=1165"},"modified":"2023-03-03T20:47:33","modified_gmt":"2023-03-04T02:47:33","slug":"node-js-fabric-js-memory-leaks-prevent-enomem","status":"publish","type":"post","link":"https:\/\/promincproductions.com\/blog\/node-js-fabric-js-memory-leaks-prevent-enomem\/","title":{"rendered":"Node JS Fabric JS Memory Leaks – Prevent ENOMEM"},"content":{"rendered":"

I’ve been working on tracking down a memory leak in my Fabric JS app running on Node JS hosted on a Rackspace cloud server<\/a>.<\/p>\n

The Problem<\/h2>\n

This server would never free up it’s used memory.  I watch the memory climb and climb on the server monitor<\/a> until it hits the dreaded drop off point.  The server runs out of memory, it throws an ENOMEM error, and forever<\/a> restarts the server.<\/p>\n

Previous Attempts To Fix This Issue<\/h2>\n

I’ve looked into this issue before and discussed it in a post about garbage collection in NodeJS<\/a>, however that sadly didn’t solve all of the issues.<\/p>\n

The other solution I’ve had in place for some time is utilizing a CRON job that will restart the server once a day in the off hours.  This will reset the memory at that time.  This hack works, but as usage has increased enough that it’s crashing before we ever get to that point.<\/p>\n

Memory Leak Debugging Process<\/h2>\n

Strip Out Code<\/h3>\n

Today I essentially stripped out code line by line to try an figure out where there could be an issue.  In your code, take out function after function, line after line until you start to notice some differences in your memory monitor.<\/p>\n

This is a manual process.  Take out some code, restart the server to get back to a baseline, run your process, and compare what the final memory usage is to what it was from your previous test.  You’ll want to grab a paper and pencil to write some numbers down.  If you think you’ve found something that made a change, undo the code change, retest, and prove that what you think you saw did happen.<\/p>\n

Memory Monitoring<\/h3>\n

I’m utilizing htop<\/a> to monitor the servers memory usage on a dev server.  (I changed my setup settings from the defaults so if the images below look different than you see that is why.)<\/p>\n

Today’s Culprit – FabricJS canvas.clear()<\/h3>\n

I found something that made a difference!  Sadly I think there still are some lingering issues out there, but this is a sizable enough change that I’m happy to have found a big issue here.<\/p>\n

It appears the canvas object isn’t being cleared properly.  I had been clearing the canvas manually via Javascript, but apparently that either isn’t the correct method or sufficient enough.  What I was doing is trying to set the canvas to null and then forcing the garbage collector to run.<\/p>\n

\/\/ Create canvas\ncanvas = fabric.createCanvasForNode( width, height );\n\n\/\/ Process the canvas with some code here\n\n\/\/ Cleanup the canvas\ncanvas = null;\nglobal.gc();<\/code><\/pre>\n
What I found today though in the FabricJS Github Issue #1997<\/a> is that there is a FabricJS method that will better cleanup these memory issues.<\/p>\n
canvas.clear();\ncanvas.dispose();<\/code><\/pre>\n
According to the source code, canvas.dispose()<\/a> calls canvas.clear() and thus technically you would only need canvas.dispose();<\/p>\n
For me, I found that canvas.dispose(); didn’t exist.  I am running an older version so it must have been added somewhere along the way.<\/p>\n
So for me, the solution I found is:<\/p>\n
\/\/ Create canvas\ncanvas = fabric.createCanvasForNode( width, height );\n\n\/\/ Process the canvas with some code here\n\n\/\/ Cleanup the canvas\ncanvas.clear();\ncanvas.interactive && canvas.removeListeners();\n<\/code><\/pre>\n
Memory Usage Results<\/h4>\n
\"Baseline<\/a>
This is the memory usage just after a server reboot.<\/figcaption><\/figure>\n
\"Memory<\/a>
After running the server process, you can see there is a memory leak. The server memory goes up and stays up. As pointed out above, this is due to not clearing the canvas created by FabricJS properly.<\/figcaption><\/figure>\n
\"Memory<\/a>
I restarted the server to get back to the baseline usage above, and then ran the process – this time using canvas.clear(); to clear the FabricJS canvas from the NodeJS server memory. As you can see there is a significant drop in the retained memory. As you can also see it didn’t go back to what the baseline was and thus there still is another leak to find. But this was a big step in the right direction!<\/figcaption><\/figure>\n
 <\/p>\n
Other Useful Information<\/h2>\n
NodeJS Streams<\/h3>\n
I didn’t find this to be the golden ticket in my debugging, but I did see plenty of discussion by other developers that using streams in NodeJS to be a better practice in regards to memory usage as opposed to reading\/writing directly from the disk.  I’m not going to try and act like an expert on this topic however – there are already great resources out there including:<\/p>\n