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 <[email protected]> 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 <[email protected]>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 >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
