On Tue, May 10, 2016 at 7:40 AM, Norman <kradepon@googlemail.com> wrote:

In this example, the amount of memory beeing allocated by the programm
converges to a limit, which shows exactly what you told me. So the C++
runtime holds on to some allocated memory, even though the objects have been
'freed', meaning that the application does not need to allocate more memory
for every function call.

My problem with this behaviour is, that my application should run for an
infinit amount of time. It's a server application, which allocates a greater
amount of memory in between. So if this memory is allocated for a little
while, even when the memory is 'not in use' anymore, that's fine with me.
But at some time, the memory needs to be released to the OS. And that's
exactly where my problem appears. I don't know, if the memory will ever be
reclaimed by the OS. Of course, RSS does not tell me how much memory my
application is currently using, but it tells me at least the minimum amount
of memory currently managed by the C++ runtime. And if this increases to a
huge amount, my OS does not have access to this memory, right?

So my remaining question is, if the ioService object will (or more precisly
the C++ runtime) will ever release the allocated memory to the OS or if i
have to do this manually.

You need to ask that question of your C++ runtime and, more specifically, the heap allocator used by the runtime.

You also need to learn how your OS manages things and when it will reclaim.

RSS is not a good indicator of leaks or even of how much memory a process is "using". All it tells you is how many OS level pages the OS currently has set aside in core for that process (or thread, if your OS gives you RSS for some more granular entity). The value of RSS depends on many things outside your control such as other processes' demands for memory, the usage patterns for memory within your process, and the like.

If you're concerned about the memory footprint of your application, you're looking at symptoms rather than real problems. Leaks are only one part of the problem. Just as common is fragmentation and locality of reference. Work to reduce those in your application, and eliminate leaks, and your app will likely exhibit better behavior with respect to memory usage.

Chris Cleeland