[asterisk-bugs] [JIRA] (ASTERISK-29340) stasis: PJSIP endpoint taskprocessor congestion after upgrading
Jan Blom (JIRA)
noreply at issues.asterisk.org
Thu Mar 18 13:48:15 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254219#comment-254219 ]
Jan Blom commented on ASTERISK-29340:
-------------------------------------
Sure. I built 16.16.2 and ran the same test as I initially did with 18.2.2, removing "decline=ast_channel_varset_type" again, since that didn't change anything.
Taskprocessor numbers has been attached.
On 16.16.2 I don't get any taskprocessor warnings.
Most taskprcessor numbers are just about the same in 16.16.2 and 18.2.2 after running a test. The only the lines that are significantly different are these:
{code:title=18.2.2}
Processor Processed In Queue Max Depth Low water High water
stasis/p:endpoint:PJSIP/proxy-00000019 1577245 0 1567 450 500
stasis/pool 86146 0 2 450 500
stasis/pool-control 172313 0 14 450 500
{code}
{code:title=16.16.2}
Processor Processed In Queue Max Depth Low water High water
stasis/p:endpoint:PJSIP/proxy-00000019 4158 0 51 450 500
stasis/pool 2143 0 1 450 500
stasis/pool-control 4307 0 16 450 500
{code}
> stasis: PJSIP endpoint taskprocessor congestion after upgrading
> ---------------------------------------------------------------
>
> Key: ASTERISK-29340
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29340
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Stasis, Resources/res_pjsip
> Affects Versions: 18.2.2
> Environment: 8 core vm, lots of RAM,
> CentOS Linux release 7.5, Asterisk 18.2.2
> Reporter: Jan Blom
> Assignee: Unassigned
> Attachments: modules 18.2.2.txt, stasis statistics 18.2.2.txt, taskprocessors 16.16.2.txt, taskprocessors 16.6.1.txt, taskprocessors 18.2.2.txt, taskprocessors decline ast_channel_varset_type.txt
>
>
> After upgrading from Asterisk 16.6.1 to 18.2.2 I notice a difference in how tasks are processed by the taskprocessors.
> My setup is that the asterisk box receives inbound calls (using chan_pjsip) from a single endpoint (SIP proxy).
> There is one taskprocessor {{stasis/p:endpoint:PJSIP/<endpoint name>}} that handles a magnitude more messages than any other taskprocessor and the max depth is well above the high watermark.
> Using the older Asterisk 16.6.1 and identical configuration, the same taskprocessor receives no messages.
> This is the taksprocessor in question, after a testrun with 4170 calls at a rate of 100 calls per second.
> bq.stasis/p:endpoint:PJSIP/proxy-00000019 1579171 0 1597 450 500
> I have attached the complete list of taskprocessors (core show taskprocessors) after a testrun. For both Asterisk versions.
> The dialplan is quite simple, only answering, playing a prompt and hangup. It also involves a few ODBC database calls. However, changing the dialplan to just answer, wait a few seconds and hangup will result in the same behavior,. Even though the number of messages processed by the taskprocessor will decrease a bit, it will still be a huge number.
> I am not entirely sure this is a problem. Calls seem to be handles properly and audio is fine. However, it is a big change in behavior compared with Asterisk 16 and a potential bottleneck if a single task is going to process a huge amount of messages. Except from this taskprocessor, all other message handling is well distributed over the various taskprocessors.
> Another annoyance is that the log gets filled with these warnings:
> bq.taskprocessor.c:1160 taskprocessor_push: The 'stasis/p:endpoint:PJSIP/proxy-00000019' task processor queue reached 500 scheduled tasks again.
> Most bells and whistles are disabled, no ARI, AMI, AGI. SIP UDP only.
> The list of loaded modules in Asterisk 18.2.2 is attached.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list