You are not logged in.
Hello Folks,
I’ve a mORMot 1.18 server that right after it is started it uses around 8MB (Debug Release) of memory according to the “Processes” Tab on the Windows Task Manager. After a couple requests, it goes a up to 9.8 MB and then forward it keep growing without ever releasing.
All services are set to TServiceInstanceImplementation.sicSingle and no sessions are being created. It is all JWT authenticated on the NGINX side.
In each service method, a DataModule is created to access the backend database (No ORM here, yet). The creation and destroying of this resource in enclosed in a Try/Finally to make sure all allocated resources are released.
I did FastMM4 diagnostic on leaks, and after fixing some dumb errors at service startup, no more leaks are reported but memory consumption still is going up.
It is my understanding that with TServiceInstanceImplementation.sicSingle every resource allocated for a Request/Thread is free once the thread is finished…
Any idea or where should I be looking for or any tips on how to further diagnose this?
Regards,
Mario
Offline
hey, the memory numbers you see in the process tab of the task manager are just a crude approximation of actual memory used. If you have a lot of heap de/allocations like in your case then you are bound to have some heap fragmentation. This means the heap memory will grow over time (but should stabilize) which is what you are observing. There's not much wrong with that since the memory manager will try to reuse the fragmented space.
Absolutely the better way is to use a memory profiler instead of the task manager. If you have to use external software then the better choice is Microsoft's Process Explorer from SysInternals (You would look at the "Private Bytes" statistic of Virtual Memory), but again, it's all just crude approximation.
Last edited by pvn0 (2021-12-18 08:02:15)
Offline
I guess this is about the memory reserved per active thread.
There is a thread pool in the mORMot server, so even if the memory is released in the code, there is still around 2MB of memory reserved when you run a thread.
So after a while, the memory consumption would stabilize around 20MB.
Try to close the server instance, and don't leave the program.
You will see the memory decrease as expected.
We have seen several mORMot servers running for years now without any restart.
And stable memory consumption.
Offline
hey, the memory numbers you see in the process tab of the task manager are just a crude approximation of actual memory used. If you have a lot of heap de/allocations like in your case then you are bound to have some heap fragmentation. This means the heap memory will grow over time (but should stabilize) which is what you are observing. There's not much wrong with that since the memory manager will try to reuse the fragmented space.
Absolutely the better way is to use a memory profiler instead of the task manager. If you have to use external software then the better choice is Microsoft's Process Explorer from SysInternals (You would look at the "Private Bytes" statistic of Virtual Memory), but again, it's all just crude approximation.
Thank you for the explanation Pvn0. I'm not really concern about the exact amount on memory used but the actual projected trend on allocation.
Regars, will take a look at the SysIternals.
regards,
Mane
Offline
Hi Ab,
Thanks your for answer. My initial thought was that I should be taking extra steps to release the allocated resources.
I was aware that a Thread Pool was working on the inside. Is this Pool size customizable?
Regards,
Mane
Offline
Thank you
Offline