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.
_______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
