[SR-Users] no private memory left after mi mt_reload command

Henning Westerholt henning.westerholt at 1und1.de
Mon Feb 21 15:49:38 CET 2011


On Monday 21 February 2011, Javier Gallart wrote:
> we are running kamailio 3.1.1. Basically for every call it has to query a
> mtree that is reloaded every 15 minutes. The mtree table is about 4M
> records and  is stored in a Pgostgres database. For the reload we use the
> command mi mt_reload embedded in a xmlrpc request. The code for this is:
> route[XMLRPC]{
>         if (method == "POST" || method == "GET")
>         {
>                 if (search("^User-Agent:"))
>                 {
>                         xlog("xmlrpc request\n");
>                         set_reply_close();
>                         set_reply_no_connect(); # optional
>                         dispatch_rpc();
>                 }
>                 exit;
>         }
> }
> This server has been running with no issued for some weeks now, but at some
> point during the weekend the mi command started to fail. This is what the
> logs show:
> 
> ERROR: <core> [db_res.c:181]: no private memory left
> ERROR: db_postgres [km_res.c:225]: could not allocate rows
> ERROR: db_postgres [km_dbase.c:280]: failed to convert rows
> ERROR: mtree [mtree_mod.c:627]: Error while fetching result
> ERROR: db_postgres [km_dbase.c:318]: invalid parameter value
> ERROR: mtree [mtree_mod.c:738]: cannot re-load info from database
> 
> I've restarted kamailio and now it's working fine. Should we increase the
> private memory? On the other hand, we'd like to detect this failure
> condition on the script and act accordingly (for instance sending an email
> with an alarm message), is there anyway to do this?

Hi Javier,

this probably caused of the fragmentation of the internal private memory pool 
from the frequent dumps and other load. You could increase the pool, or better 
- switch the MI to the system memory pool by uncommenting this line in 
kmi/Makefile

#DEFS+= -DMI_SYSTEM_MALLOC

and recompile the server.

Cheers,

Henning



More information about the sr-users mailing list