You are going to like me Sundance kid...
I'm going to say that you are right again.
This is very unlikely to be a Unix bug, swapping problem or any to that stuff. There is no indication that the system is not simply doing what it is told. There are multiple memeory managers. There is the VM/page manage in the os at a global level. But within each process there is the malloc/free (or alternatives) process local memory manager which requests large chunks of VM from the OS (check: man brk, man sbrk) and then parcels out smaller pieces.
> Could there be such thing as virtual memory fragmentation?
Yes. It is often called 'laddering'. It is often attempted to be solved through 'binary buddy' system. Here is a sample scenario:
malloc 5kb(1) temp, 5kb(2) temp, release 5kb(1), malloc 3kb(3) permanent. That 3Kb might fit the first 5kb hole leaving 2kb unused. Repeat often enough and you'll be inefficient, but it will not be deadly.
For it to become deadly it needs to be combined with an optimization algoritme in the process vm manager (like a size based look-aside list), and very unlucky allocation patterns. Notably where the application hangs on to small morcels of malloced data, with large holes between them.
Or... much more simple... the application 'forgets' about malloced data, never freeing it, but never re-using it either!
Time to go back to the software vendor or perhaps an inhouse applciation development group. They would then likely use tools like 'Electric Fence' to locate the problem.
(Google for : +malloc +leak +tool)
> But does it impact swap/RAM usage? I'd say no, it is only in the virtual memory
It is VM, but you touched it, dirtied it and thus the system is obliged to remember it! It does nto know you might not come back for it. And in fact you might be coming back for 10 bytes every 4kb. If you don't come back, it can just swap out and it will not hurt too much as long as you have swap space. But it may trigger ugly memory reclaim algoritmes and may the system in general.
Hein.
