[sr-dev] A script function to get the reamining PKG MEM

Henning Westerholt henning.westerholt at 1und1.de
Fri Apr 16 13:49:08 CEST 2010


On Friday 16 April 2010, Iñaki Baz Castillo wrote:
> - A request arrives and it's handled by a worker process.
> - There is some memory leak in PKG MEM (or perhaps too few memory
> allocated for it).
> - The process still can do basic tasks as parsing and so.
> - The script creates a dialog and does other operation requiring SHM
>  memory. 
> - When calling to t_relay() it fails due to non enough PKG mem, so
>  the transaction is not created.
> - Also depending on the memory status it's possible that the process
> can not generate a SIP error response (so there is no response).
> - The client starts with retransmissions.
> - These retransmissions would not match an existing transaction so all
> the script process is done again (creating a new dialog and so).
> - Again t_relay() fails.

Hello Inaki,

transaction live mainly in shared memory, so this could be another reason that 
the t_relay/ t_newtran fails. But you're right, it should also fail due 
insufficient private memory .
 
> So what I'm in mind is a new script function to get the current
> available PKG mem, so the script can determine not to process the
> request and reply (if it can) an error response. This would avoid the
> creation of a new dialog, db queries and so on.

There are already some functions that output mem status, albeit in the log. 
Take a look to pkg_status/shm_status() in cfgutils. So one could of course 
implement a PV that returns the number of available memory, or a function that 
checks for a certain range.

But i wonder if this is really necessary. The last out of memory condition we 
observed in production is years away, if i remember correctly. So i'd suggest 
that you just use a proper size of PKG mem pool (like 10MB per process) and 
also enough shared memory, as RAM is really cheap this days. If then you still 
get a out of memory condition then there is a memory leak in the code, and 
this should just be fixed instead of trying to work around in the script here.

Best regards,

Henning



More information about the sr-dev mailing list