|
<< Click to Display Table of Contents >> Navigation: Telegram > 2021 > 10 > 31 > Telegram_2021-10-31T17 |
2021-10-31T17:01:42
It sounds like you have a memory leak. Turn on the built in leak detection.
2021-10-31T17:45:38
You are looking at the wrong column there.
The commit size is the sum of the real physical memory + all the page file size allocated for that process. Your MySQL has a committed size of 40 Gb but it is only consuming 3 Gb of RAM. It means that somewhere in your HDD, Windows is allocating 37 Gb in a page file for it
Something similar with the ORACLE process.
2021-10-31T17:46:14
You need to pay attention to the Working Set size, not the committed size
2021-10-31T17:49:22
and I don't see anything wrong with your process either, per se. It is consuming 1.3 Gb of RAM. You are pointing out that there are no active sessions, but look at the data sent size (130 Mb): Your process served 130 Mb of data to user sessions previously (I don't know exactly how many) and FastMM 4 is well known for not returning the allocated memory to the OS unless it needs to.
So, even though your process has 1.3 Gb of memory still allocated, it is possible that a big part of it is unused, still allocated in FastMM memory pool
2021-10-31T17:50:21
I suggest you run the FastMM in full debug mode, so you can detect any memory leaks. If there are none, then there is nothing to worry about.
There is a detailed how to here:
type: link https://www.atozed.com/2021/07/detecting-memory-leaks-in-delphi-applications-using-fastmm-4/