- edited description
How to free memory manually
I noticed that in a websocket application, when the free memory
gets low , the microblocks websocket service stops serving (client blocked) until the value shown in the free memory
automatically gets larger and the service becomes normal again
Comments (12)
-
reporter -
reporter - edited description
-
reporter - edited description
-
reporter I had a similar problem with the Microblocks http server before, where after multiple requests-responses, there would be a client request that could not be responded to, but then next request would resume, seemingly due to the automatic garbage collection.
In these cases, it seems that if I can manually free the memory, I can avoid the problem.
-
repo owner It should not be necessary to force a garbage collection (GC) since the system will do it automatically when needed.
However, if you want to experiment, you can try to allocate a huge object, such as a million element list:
That will give an error but will force a GC.
You can also click the stop button to clear all variables and free all objects. If you click the "free memory" right after that -- before running any scripts -- you'll see how much dynamic memory (in bytes) is available in MicroBlocks on your board.
It is possible that the problems you are seeing are because MicroBlocks is running out of memory so it cannot allocate memory for new objects, even after a GC. That could happen if, for example, you were collecting incoming data in a list. In that case, you'd need to remove unused items from the list to allow the memory to be recycled.
Another possibility is that requests are arriving faster than they can be handled, thus creating a temporary memory shortage. A garbage collection operation takes a few milliseconds, which might cause a backup. Writing data to the Flash file system can be very slow. A possible fix for such timing issues is to slow down the sending program.
Note that the ESP32 has much more RAM available for MicroBlocks than the ESP8266. If you are experienced problems on an ESP8266 you might try running the same program on an ESP32.
-
reporter It is possible that the problems you are seeing are because MicroBlocks is running out of memory so it cannot allocate memory for new objects, even after a GC. That could happen if, for example, you were collecting incoming data in a list. In that case, you'd need to remove unused items from the list to allow the memory to be recycled.
Yes! It was exactly what I was having trouble with, and with your tips, it's working perfectly now!
Thanks John!
Another possibility is that requests are arriving faster than they can be handled, thus creating a temporary memory shortage. A garbage collection operation takes a few milliseconds, which might cause a backup. Writing data to the Flash file system can be very slow. A possible fix for such timing issues is to slow down the sending program.
This tip is also very important!
-
repo owner Glad you got it working!
What board were you using? You're more likely to hit memory issues on an ESP8266 than an ESP32. All microcontrollers have tiny amounts of RAM compared to the multiple gigabytes we have modern desktops, laptops, and mobile devices. Even a $5 Raspberry Pi Zero has 512 megabytes of RAM, thousands of times more than most microcontrollers. When you're used to have so much memory, it's hard to remember that RAM is a scarce resource on microcontrollers.
-
reporter What board were you using?
I am currently using ESP32, this problem is solved by reseting the list variable in time.
When you're used to have so much memory, it's hard to remember that RAM is a scarce resource on microcontrollers.
Yes, it is : ) It has another kind of fun.
-
reporter - changed status to resolved
-
repo owner It has another kind of fun.
Yes, I also find it fun work in the constrained world of microcontrollers. :-)
-
reporter Art is dancing with shackles . Programming, sometimes, is an art disguised as a science : -)
-
reporter I think Microblocks is an elegant art :-)
- Log in to comment