[asterisk-bugs] [JIRA] (ASTERISK-26088) Investigate heavy memory utilization by res_pjsip_pubsub

[Friendly Automation (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=237017#comment-237017 ] 

Friendly Automation commented on ASTERISK-26088:
------------------------------------------------

Change 5631 merged by Jenkins2:
res_pjsip_session.c: Process initial INVITE sooner. (key exists)

[https://gerrit.asterisk.org/5631|https://gerrit.asterisk.org/5631]

> Investigate heavy memory utilization by res_pjsip_pubsub
> --------------------------------------------------------
>
>                 Key: ASTERISK-26088
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26088
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Core/Sorcery, Core/Stasis, Resources/res_pjsip, Resources/res_pjsip_pubsub, Resources/res_pjsip_registrar
>    Affects Versions: 13.9.1
>            Reporter: Richard Mudgett
>            Assignee: Richard Mudgett
>      Target Release: 13.10.0, 14.0.0
>
>
> Under *heavy* subscribe/unsubscribe load Asterisk will keep consuming memory until the process runs out of memory.
> Using a sipp scenario that does the following for each user:
> # REGISTER
> # SUBSCRIBE to 8 extens
> # wait
> # unSUBSCRIBE from those extens
> # unREGISTER
> When simulating a lot of user endpoints the system taskprocessors get backed up.  This can be seen by running CLI "core show taskprocessors" and watching several taskprocessors get backlogged.
> Another thing noticed during investigation is that these messages were seen a lot:
> {noformat}
> sip_transactio Unable to register REGISTER transaction (key exists)
> sip_transactio Unable to register SUBSCRIBE transaction (key exists)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)