Is the memory not reclaimed for Delphi apps running on Windows Server 2008 (sp1)?

Question

We have a D2007 application whose memory footprint grows steadily when running on Windows Server 2008 (x64, sp1).
It behaves normally on Windows Server 2003 (x32 or x64)

Answer 1

In addition to Alexander, usually this is called "heap fragmentation".

Note that FastMM is supposed to be more resilient and faster overall, but if the original app was tuned for the D7 memmanager, FastMM might actually perform worse.

Answer 2

Well, memory usage can increase even if there is no memory leak in your application. In those cases there is possibility than you have leak of another resource. For example, if your code allocates, say, a bitmap and though it releases all objects, but manages to forget about finalizing some HBITMAP.

FastMM will tell you that you have no memory leak in your application, since you've freed all of your objects and data. But you still leaks other types of resources (in my example - GDI objects). Leaking other types of resources can affect your memory too.

I suggest you to try other tool, which checks not only memory leaks, but other types of leaks too. I think that AQTime is capable of doing that, but I'm not sure.

Another possible reason for this behaviour is memory fragmentation. Suppose you mave allocated 2000 objects of 1 Mb in size (let's forget for a minute about MM overheads and presence of another objects in user space). Now you have full 2 Gb of busy memory. Now, suppose that you free all even objects, so now you have "stripped" memory space, where 1 Mb busy and free blocks are mixed. Though you now do have 1 Gb of free memory, but you are not able to allocate a memory for any 2Mb-object, since the maximum size of free block is 1 Mb only (but you do have 1000 of such blocks ;) ). If memory manager used blocks larger than 1 Mb for your objects, then it can not release memory blocks back to OS, when you've freed your even objects:

[ [busy] [free] [busy] [free] [busy] [free] ]
[ [busy] [free] [busy] [free] [busy] [free] ]...

Those large [...] blocks are half-busy, so MM can not give them to OS. If you'll ask for another block, which is > 1 Mb then MM will need to allocate yet another block from OS:

[ [busy] [free] [busy] [free] [busy] [free] ]
[ [busy] [free] [busy] [free] [busy] [free] ]...
[ [your-new-object] [free.................] ]

Note, that these are just examples of incresing memory usage, though you do not have memory leak. I do not say that you have the EXACT situation :D