Summary: | ASTERISK-26088: Investigate heavy memory utilization by res_pjsip_pubsub | ||||||
Reporter: | Richard Mudgett (rmudgett) | Labels: | |||||
Date Opened: | 2016-06-06 11:57:07 | Date Closed: | 2016-06-09 16:47:11 | ||||
Priority: | Major | Regression? | |||||
Status: | Closed/Complete | Components: | Core/Sorcery Core/Stasis Resources/res_pjsip Resources/res_pjsip_pubsub Resources/res_pjsip_registrar | ||||
Versions: | 13.9.1 | Frequency of Occurrence | |||||
Related Issues: |
| ||||||
Environment: | Attachments: | ||||||
Description: | 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} | ||||||
Comments: | By: Friendly Automation (friendly-automation) 2017-05-17 11:32:54.205-0500 Change 5632 merged by Jenkins2: res_pjsip_session.c: Process initial INVITE sooner. (key exists) [https://gerrit.asterisk.org/5632|https://gerrit.asterisk.org/5632] By: Friendly Automation (friendly-automation) 2017-05-17 11:40:51.247-0500 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] By: Friendly Automation (friendly-automation) 2017-05-17 11:41:57.155-0500 Change 5630 merged by Jenkins2: res_pjsip_session.c: Process initial INVITE sooner. (key exists) [https://gerrit.asterisk.org/5630|https://gerrit.asterisk.org/5630] |