This is actually expected behavior of Unix-like OSes in general. RPD may in fact have released the memory (using free()) but will still have that RAM associated with it. This is due to the fact that Unix (BSDlike esp) generally use brk() or sbrk() under the hood during malloc() to request more RAM from the OS. There's actually no way for a process to return memory to the OS. Recent versions of POSIX have removed brk/sbrk from the standard...but I believe at heart that libc/glibc still use this mechanism to extend their address space/request more RAM from the OS. brk() can in theory reduce this allocation but I do not believe free() attempts this, and the only thing brk() can do anyway is set the end of the address space, so unless your memory space is defragmented you may end up with memory used at the end of the space keeping everything allocated.
Memory management under the hood gets really complicated obviously. In general on Unix-like OSes it's expected a processes memory utilization will grow to a peak, and then stay there. So the OS and it's interfaces are built around this (very reasonable, and in general very true) assumption. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp