Question

Database node operating memory vs committed and non committed objects

1

The monitor function can sometimes be complex so I would like to know if my reasoning is sound. We have the following environment: As one can see from the purple line something needs to be done here on this environment. The quick fix would be to add an app engine and everything should be fine again. The point is imho that this can always be the last resort. I first need to comprehend why this is happening. Because if I know the why I may be can solve this in the model instead of just throwing more resources in. Now the why part. When we look at the cached objects we see that a user could easily have 500+ objects in a user session. Inspecting this further it would always lead to the same non-persistent entity that used large quantities. (As a side question I do wonder when these non-persistent objects would be purged from memory. Would that be when the form was closed that held these objects? Or would they be cleaned when the user logs out?) Now my assumption. Since non-persistent objects always uses server memory would changing this object from non-persistent to persistent change the memory consumption of the server? Because then it would have no need to held these objects in memory and it would only retrieve the objects that are actually needed. The database would grow offcourse but that would not be a problem. I like to hear from anyone if my assumption is correct. If not I would like to know how I could analyse this further. Again from a Mendix standpoint the quick fix would be prefered :) but I wonder what I can do as a modeler to fix these kind of problems. Regards, Ronald [EDIT] We sometimes have issues with this environment. As response from support we got this message: "We can see that the committed memory on the database exceeds the current ram (see graph: Database node operating system memory) so it would be advised to increase it." But I am still wondering what influances the database memory. According to the docs: 10.2 Memory The memory graph shows the distribution of operating system memory that is available for this server. The most important part of this graph is the 'cache' section. This type of memory usage contains parts of the database storage that have been read from disk earlier. It is crucial to the performance of an application that parts of the database data and indexes that are referenced a lot are always immediately available in the working memory of the server, at the cache part. A lack of disk cache on a busy application will result in continuous re-reads of data from disk, which takes several orders of magnitude more time, slowing down the entire application. I wonder in which part of the memory non persistent objects end up. My assumption was that non persistent objects are like an Index table and thus would end up in the database server memory and not in the application memory. The application memory graph is fine. We never go out of memory and have a stable small red line there. [EDIT2] Could somebody from Mendix chime in here about the question in which part of the memory the non committed objects end up?

asked 2016-02-16

Ronald Catersels

2 answers

Pieter van de Braak · Answer 1 · 2016-02-16

As a side question I do wonder when these non-persistent objects would be purged from memory.

non-persistent objects are purged all the time, as soon as Mendix notices that they are no longer referenced to, they are dropped.

Since non-persistent objects always uses server memory would changing this object from non-persistent to persistent change the memory consumption of the server?

You would be right if the memory consumption of your application was too high, however, if i interpret the title of the image correctly this concerns the database server. That is why I would suspect an even higher memory consumption. The database server is not burdened with non-persistent entities, thus i do not believe that using them will increase the memory usage of your database server.

Changing your non-persistent entities to persistent ones would mean extra tasks for your database server and might even increase it's memory load.

Edit: In reply to Nikel i found the following here

Committed memory is, essentially, all the memory which has been allocated by applications, whether it's used or not. In contrast, the "apps" is memory that is allocated AND used.

That means that the purple line is the memory that could be used if all applications would use all their allocated memory. I assume that the only reason this gets higher then the maximum amount of memory available is if the OS is set to use a constant amount while the database increases it's memory use due to a high load. This on turn is also visible by the green area in the graph.

What i still don't understand though is what the non-persistent objects have to do with your memory increase, are you sure no persistent objects are stored as well?

Nikel Kruizinga · Answer 2 · 2016-02-16

As one can see from the blue line something needs to be done here on this environment.

Nope, I can't. To be able to do this I would have to understand what the purple (I assume you mean purple instead of blue) line means. I have done some research on this and have no idea what it means, and what it means that it is higher than the 2G boundary (which seems to have some kind of meaning).

What I can tell from experience is that when this happens your database will stop accepting new connections, which is a problem.

I think a normal amount of memory for a database to have is 8GB or 16GB. So if my database running on 2GB is running out of memory I am not worried. Especially when I am using a platform that gives me almost zero control over caching, fetching and transaction behavior.