On 06/02/2016 12:04 PM, [email protected] wrote:
I'm dealing with a very long-running simple real-time program (weeks,
even months) which opens and closes sockets continually to a variety
of locations, for very short transactions. There is very slow
growth of virtual and real memory use (especially the real memory) of
this program, on a variety of *NIX types and apparently proportional
to the activity level, that raises the following questions:
- I assume that the kernel has to allocate buffer space for each
socket created, which presumably it charges to the pid of the socket
requester (the problem perl program in this case)?
- I once ran across a comment somewhere in perldoc or code comments
that when perl requests memory from the system it *never* gets
released back to the system -- perl may reuse it itself after getting
it garbage collected, but it doesn't get returned to the kernel.
Could have been a very old piece of doc -- is this still true?
- Strictly speaking perl isn't directly requesting the buffer memory,
just the socket, so I'm not sure that even if the statement above is
true that the buffer space doesn't go back to the system when the
socket closes.
- Sooooo, it's a long way of asking if closing the socket in perl
returns the buffer memory back to the system?
- And finally, if the buffer memory does stay with the perl pid, is
perl actually able to use that memory later for other purposes (since
it seems like an indirect memory allocation) ?
PS I realize that socket work is not generally done this way (i.e. so
long-running) but would like to better understand the situation before
undertaking restructuring.
if you properly close the sockets then any kernel allocations will be
freed up by the kernel. you shouldn't see any leak or growth from that.
if you are seeing slow growth it means you have a leak in your own code.
unless you found a bug in perl and it is leaking for you but that is
unlikely.
as for socket work being done this way, i can't tell you as i don't know
what you are actually doing. many socket based programs run for a long
time. some like apache will stop and restart processes to clean up any
possible leaks. that could be a solution as you claim it doesn't do much
work so you have many time slots to force a restart.
perl itself can't easily give back ram to the system. it is hard for any
process to do that (can't explain quickly but it involves calling
brk/sbrk with ram at the top of the heap). so i would look carefully at
how you manage your sockets and see if you can find a leak. or add
restart logic.
thanx,
uri
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
