[Serdev] t_newtran() causing SHM exhaustion

Jan Janak jan at iptel.org
Tue Mar 1 07:53:55 UTC 2005


Transactions created with t_newtran must be replied with t_reply at some
point, otherwise they will be kept in memory.

Currently it is not possible to use t_newtran with save function,
because it would send the reply statelessly. I have a patch from Maxim
that would allow that, I plan to commit the patch soon.
  
  Jan.

On 01-03 10:02, Paul Jankowski wrote:
> Hi,
> 
> I'm finding that t_newtran() can cause ser to use up all its shared
> memory in as little as a day in a production environment (and less than
> three minutes using a "while ( true ) ; do sipsak ... ; done" type
> command).
> 
> This is a clean 0.8.14 install with no meaningful changes to ser.cfg
> except the following:
> 
>   if (method=="REGISTER") {
>       # [...]
>       if (t_newtran())
>       {
>           save("location");
>       };
>       break;
>   };
> 
> The first time a user registers, roughly 3kB of SHM is allocated and
> cloned, then the two instances are freed.  However, subsequent
> registrations by the same user are not freed (sample stderr output
> below).
> 
> The default 32MB of SHM is filled up after about 10,500 sipsak
> registrations, or roughly 30,000 real registrations in a production
> environment.
> 
> Questions:
>   1. Why does t_newtran() exhibit this behaviour, that the first
>      registration's memory is freed but no later registrations' --
>      shouldn't this be the other way around?
>   2. What factors determine when delete_cell() clears out a transaction?
>   3. Am I using t_newtran() the wrong way?
> 
> Cheers,
> 
> Paul
> 
> PS. First three registrations show up in stderr as follows:
>  0(25091) qm_malloc(0x1ba12000, 2992) called from h_table.c: build_cell(220)
>  0(25091) qm_malloc(0x1ba12000, 2992) returns address 0x1bb9d548 frag. 0x1bb9d530 (size=2992) on 1 -th hit
>  0(25091) qm_malloc(0x1ba12000, 2568) called from sip_msg.c: sip_msg_cloner(373)
>  0(25091) qm_malloc(0x1ba12000, 2568) returns address 0x1bb9e128 frag. 0x1bb9e110 (size=2568) on 1 -th hit
> ...
>  1(25093) qm_free(0x1ba12000, 0x1bb9e128), called from h_table.c: free_cell(117)
>  1(25093) qm_free: freeing frag. 0x1bb9e110 alloc'ed from sip_msg.c: sip_msg_cloner(373)
>  1(25093) qm_free(0x1ba12000, 0x1bb9d548), called from h_table.c: free_cell(153)
>  1(25093) qm_free: freeing frag. 0x1bb9d530 alloc'ed from h_table.c: build_cell(220)
> ...
>  0(25091) qm_malloc(0x1ba12000, 2992) called from h_table.c: build_cell(220)
>  0(25091) qm_malloc(0x1ba12000, 2992) returns address 0x1bb9d548 frag. 0x1bb9d530 (size=2992) on 2 -th hit
>  0(25091) qm_malloc(0x1ba12000, 2568) called from sip_msg.c: sip_msg_cloner(373)
>  0(25091) qm_malloc(0x1ba12000, 2568) returns address 0x1bb9e128 frag. 0x1bb9e110 (size=2568) on 1 -th hit
> ...
>  0(25091) qm_malloc(0x1ba12000, 2992) called from h_table.c: build_cell(220)
>  0(25091) qm_malloc(0x1ba12000, 2992) returns address 0x1bb9eb60 frag. 0x1bb9eb48 (size=2992) on 1 -th hit
>  0(25091) qm_malloc(0x1ba12000, 2608) called from sip_msg.c: sip_msg_cloner(373)
>  0(25091) qm_malloc(0x1ba12000, 2608) returns address 0x1bb9f740 frag. 0x1bb9f728 (size=2608) on 1 -th hit
> 
> -- 
> P-a-u-l- -J-a-n-k-o-w-s-k-i                              paul at teragen.com.au
> 
>  "A programmer," he said with obvious amazement, is the sort of person "who
>  drinks Coke in the morning."  -- Boston Globe article on The High Tech Set
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev




More information about the Serdev mailing list