Building apps with the Mendix platform is very easy. You create the domain models, microflows and pages and press start. Mendix will start everything what is needed to run your application. Mendix makes sure that all your data is stored in the database and it's available in your microflows. As a business engineer it's a great a simple platform.
For the technical engineer I want to go a step further, because something makes Mendix run on the operating system. We all know that Mendix uses Java, an easy piece of middleware between Mendix and the OS. Java will handle the usage of memory and CPU on the OS. In my experience with Mendix the 'Out of Memory' exception is the most difficult one: an application that crashes on memory resources and isn't available any more. To understand how and why an OoM (Out of Memory exception) is triggered, we must first look how the Java memory works.
The Java memory is divided in separate parts: young generation, old generation (the Java heap) and the permanent generation. The permanent generation is the memory place to load in all classes and libraries. Default it has a size 64Mb, but at Mendix it's on 128Mb, what is enough. The young and the old generation is the place what we're going to discuss. All objects that are in memory (non-persistent entities, microflow objects, page objects, etc.) are stored there. The ratio between the young and old generation is 1:3, so the old generation is 3 times bigger than the young generation. The young generation small but fast and the old is large but slow.
When a microflow is started and is creating objects, the objects are pushed to the young generation. The generation keeps growing in size until it's reaching his max. At that point a minor garbage collection (short: minor GC) is triggered, removing all objects that aren't used anymore, making room for new objects. The minor GC doesn't take any resources, so you don't notice it's running. The objects that are still used, are of course saved. Those objects cannot be all the time in the young generation!
When an object survives 2 minor garbage collections it will be transfer to the old generation. The old generation is bigger and holds more objects/data. It haves more impact when that generation needs to be cleaned: a major garbage collection (short: major GC).
At the graph above you see a Mendix app that is running about memory usage. The purple part is the young generation and the red is the old generation. Give a good look at the purple part, you see a saw structure, up and down. The red part is the old generation with 1 saw spike. Each time when the spike goes down a garbage collection is triggered. The minor GC happens a lot more than the major GC.
Mendix uses Java with that memory setup. All objects that are created and used are stored, starting, in the young generation and after in the old generation. Each generation uses garbage collection to make room for new objects. This means that the garbage collection runs in iterations: fill up, GC, fill up, GC, etc.
In the next blogpost I will discuss how and why Out of Memory exception are triggered, viewing all kind of Java memory graphs. How to read those graphs and placing them in context with other graphs.
For the technical engineer I want to go a step further, because something makes Mendix run on the operating system. We all know that Mendix uses Java, an easy piece of middleware between Mendix and the OS. Java will handle the usage of memory and CPU on the OS. In my experience with Mendix the 'Out of Memory' exception is the most difficult one: an application that crashes on memory resources and isn't available any more. To understand how and why an OoM (Out of Memory exception) is triggered, we must first look how the Java memory works.
The Java memory is divided in separate parts: young generation, old generation (the Java heap) and the permanent generation. The permanent generation is the memory place to load in all classes and libraries. Default it has a size 64Mb, but at Mendix it's on 128Mb, what is enough. The young and the old generation is the place what we're going to discuss. All objects that are in memory (non-persistent entities, microflow objects, page objects, etc.) are stored there. The ratio between the young and old generation is 1:3, so the old generation is 3 times bigger than the young generation. The young generation small but fast and the old is large but slow.
When a microflow is started and is creating objects, the objects are pushed to the young generation. The generation keeps growing in size until it's reaching his max. At that point a minor garbage collection (short: minor GC) is triggered, removing all objects that aren't used anymore, making room for new objects. The minor GC doesn't take any resources, so you don't notice it's running. The objects that are still used, are of course saved. Those objects cannot be all the time in the young generation!
When an object survives 2 minor garbage collections it will be transfer to the old generation. The old generation is bigger and holds more objects/data. It haves more impact when that generation needs to be cleaned: a major garbage collection (short: major GC).
Mendix uses Java with that memory setup. All objects that are created and used are stored, starting, in the young generation and after in the old generation. Each generation uses garbage collection to make room for new objects. This means that the garbage collection runs in iterations: fill up, GC, fill up, GC, etc.
In the next blogpost I will discuss how and why Out of Memory exception are triggered, viewing all kind of Java memory graphs. How to read those graphs and placing them in context with other graphs.
