[OpenSIPS-Users] pkmem statistics oddity

[Jeff Pyle]

The same behavior has appeared on the same system, this time causing it to
stop functioning.  Logs show:

opensips[21368]: ERROR:core:parse_from_header: out of pkg_memory
opensips[21368]: ERROR:uac:restore_uris_reply: failed to find/parse FROM hdr
opensips[21368]: WARNING:core:fm_malloc: Not enough free memory, will
atempt defragmenation
opensips[21368]: ERROR:core:parse_from_header: out of pkg_memory
opensips[21368]: ERROR:uac:restore_uris_reply: failed to find/parse FROM hdr
opensips[21368]: WARNING:core:fm_malloc: Not enough free memory, will
atempt defragmenation
opensips[21368]: ERROR:core:build_res_buf_from_sip_res: out of pkg mem
opensips[21368]: ERROR:tm:relay_reply: no mem for outbound reply buffer
opensips[21368]: WARNING:core:fm_malloc: Not enough free memory, will
atempt defragmenation
opensips[21368]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory
 ; needs 410
opensips[21368]: WARNING:core:fm_malloc: Not enough free memory, will
atempt defragmenation
opensips[21368]: ERROR:uac_auth:build_authorization_hdr: no more pkg mem
opensips[21368]: ERROR:uac_registrant:reg_tm_cback: failed to build
authorization hdr
opensips[21369]: WARNING:core:fm_malloc: Not enough free memory, will
atempt defragmenation
opensips[21369]: ERROR:uac_auth:build_authorization_hdr: no more pkg mem
opensips[21369]: ERROR:uac_registrant:reg_tm_cback: failed to build
authorization hdr
...

The load is low, measured in "seconds between calls" rather than "calls per
second".  Total number of dialogs is less than 20.  There are two children
processes defined.  The script is very simple; its main role is to relay
INVITEs from one interface to another while handling the media with
rtpproxy.  Shared memory is 16M and pkg memory is 1M.

I'll try to follow the memory troubleshooting
steps<http://www.opensips.org/Documentation/TroubleShooting-OutOfMem>to
see if anything interesting surfaces.  Any other recommendations are
always appreciated.


Regards,
Jeff


On Tue, Sep 17, 2013 at 11:07 AM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:

> Update:  On an OpenSIPS instance that has been running for a while (at
> least days), the first iteration of get_statistics will show the
> zero-values.  Running it again, the zeros have been replaced by values that
> make sense.
>
> Could the act of running get_statistics cause memory behavior to change?
>  That's how it seems.  Unless the reporting is wrong somehow.
>
>
> - Jeff
>
>
>
> On Tue, Sep 17, 2013 at 11:01 AM, Jeff Pyle <jpyle at fidelityvoice.com>wrote:
>
>> Hello,
>>
>> We're trying to track down a memory problem on OpenSIPS 1.9.1 compiled
>> from github (so no rev number) on Aug 13.  I noticed something weird I
>> wanted to present for opinions.
>>
>> # opensipsctl fifo get_statistics all | grep ^pkmem"
>> pkmem:0-total_size = 1048576
>> pkmem:0-used_size = 107128
>> pkmem:0-real_used_size = 163960
>> pkmem:0-max_used_size = 165960
>> pkmem:0-free_size = 884616
>> pkmem:0-fragments = 61
>> pkmem:1-total_size = 1048576
>>  pkmem:1-used_size = 133960
>> pkmem:1-real_used_size = 192496
>> pkmem:1-max_used_size = 192496
>> pkmem:1-free_size = 856080
>> pkmem:1-fragments = 58
>> pkmem:2-total_size = 1048576
>> pkmem:2-used_size = 107112
>> pkmem:2-real_used_size = 163944
>> pkmem:2-max_used_size = 165960
>> pkmem:2-free_size = 884632
>> pkmem:2-fragments = 61
>> *pkmem:3-total_size = 0*
>> *pkmem:3-used_size = 0*
>> *pkmem:3-real_used_size = 0*
>> *pkmem:3-max_used_size = 0*
>> *pkmem:3-free_size = 859336*
>> *pkmem:3-fragments = 0*
>> pkmem:4-total_size = 1048576
>> pkmem:4-used_size = 129384
>>  pkmem:4-real_used_size = 188544
>> pkmem:4-max_used_size = 197616
>> pkmem:4-free_size = 860032
>> pkmem:4-fragments = 112
>> pkmem:5-total_size = 1048576
>> pkmem:5-used_size = 115624
>> pkmem:5-real_used_size = 173656
>> pkmem:5-max_used_size = 181816
>> pkmem:5-free_size = 874920
>> pkmem:5-fragments = 102
>> pkmem:6-total_size = 1048576
>> pkmem:6-used_size = 115632
>> pkmem:6-real_used_size = 173760
>> pkmem:6-max_used_size = 181960
>> pkmem:6-free_size = 874816
>> pkmem:6-fragments = 106
>> pkmem:7-total_size = 1048576
>> pkmem:7-used_size = 115280
>> pkmem:7-real_used_size = 172112
>> pkmem:7-max_used_size = 172112
>> pkmem:7-free_size = 876464
>> pkmem:7-fragments = 59
>> pkmem:8-total_size = 1048576
>> pkmem:8-used_size = 115280
>> pkmem:8-real_used_size = 172112
>> pkmem:8-max_used_size = 172112
>> pkmem:8-free_size = 876464
>> pkmem:8-fragments = 59
>> pkmem:9-total_size = 1048576
>>  pkmem:9-used_size = 106808
>> pkmem:9-real_used_size = 163544
>> pkmem:9-max_used_size = 165960
>> pkmem:9-free_size = 885032
>> pkmem:9-fragments = 61
>> pkmem:10-total_size = 1048576
>> pkmem:10-used_size = 115248
>> pkmem:10-real_used_size = 172128
>> pkmem:10-max_used_size = 173040
>> pkmem:10-free_size = 876448
>> pkmem:10-fragments = 62
>>
>>
>> Looking at pkmem:3, is it normal to have the 0s in total_size, used_size,
>> etc?  I restarted opensips and now they all have a total_size.
>>
>>
>> - Jeff
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130923/5a337366/attachment.htm>