Taskprocessor overload on non-udp transport

I’ve been using Asterisk 16.17.0 + PJSIP + WebRTC + DAC and receiving the following message:

res_pjsip/pjsip_distributor.c: Taskprocessor overload on non-udp transport.

Any ideas?

Thanks

There’s a taskprocessor overload. You’d need to examine “core show taskprocessors” to see what taskprocessor overloaded, which can then provide a clue on what exactly is overloading the system. A taskprocessor overload occurs when work can’t be handled fast enough.

I thought: res_pjsip/pjsip_distributor.c would say which taskproccessor overloaded.

It does not. It merely states that there is an overload of a taskprocessor.

OK.

Well, i do have 1492 taskprocessors running.

asterisk -rx “core show taskprocessors”

Processor Processed In Queue Max Depth Low water High water
app_voicemail 0 0 0 450 500
ast_msg_queue 0 0 0 450 500
CCSS_core 0 0 0 450 500
dns_system_resolver_tp 0 0 0 450 500
iax2_transmit 0 0 0 450 500
pjsip/default-0000000f 21338 0 2 450 500
pjsip/default-00000010 122 0 2 450 500
pjsip/default-00000011 1 0 1 450 500
pjsip/default-00000012 0 0 0 450 500
pjsip/default-00000013 0 0 0 450 500
pjsip/default-00000014 0 0 0 450 500
pjsip/default-00000015 0 0 0 450 500
pjsip/default-00000016 0 0 0 450 500
pjsip/distributor-0000025a 794 0 3 450 500
pjsip/distributor-0000025b 1168 0 3 450 500
pjsip/distributor-0000025c 1300 0 3 450 500
pjsip/distributor-0000025d 1334 0 4 450 500
pjsip/distributor-0000025e 2288 0 3 450 500
pjsip/distributor-0000025f 845 0 3 450 500
pjsip/distributor-00000260 700 0 3 450 500

Which info exactly should I check? Thanks.

If “Max Depth” exceeds “High water” then it overloaded. There’s also a blog post with a bit of info in general[1].

[1] Asterisk Task Processor Queue Size Warnings ⋆ Asterisk

Hmmm, That’s new for me, Thank you.

The only taskprocessor that exceeded its “High Water” is:
Processor Processed In Queue Max Depth Low water High water
stasis/pool-control 159805466 0 2135 450 500

I’m kind of lost how to manage that?

Any help is more than welcome.

Thanks

Pool control is used for the internal message bus. The system may not have enough resources to do what you are doing, or something else is using resources. To isolate things you have to find out what about your specific usage is the trigger. I don’t have a magic answer to solve it immediately because there isn’t one.

I’m aware that nobody has a magical number, there’s no need to say that.

I’ve been an Asterisk user for the past 15 years, and I must say documentation has never been the best part of Asterisk.

But, thanks anyway. I’ll keep checking on stasis setup.

Have a great week.

Hi @jcolp

I’ve read the Blog you’ve sent me, made a few changes on the following files, but it doesn’t change its behavior.

pjsip.conf:
[system]
threadpool_initial_size=64
threadpool_auto_increment=16
threadpool_idle_timeout=15
threadpool_max_size=384

stasis.conf:
[threadpool
initial_size = 16
idle_timeout_sec = 15
max_size = 0

Any help is welcome.

Thanks in advance.

Then you have to identify what about your specific usage pattern is triggering such high number of events to be raised. The system characteristics itself, what you’re doing in dialplan, how many calls and calls per second, all of that stuff.

I found this on my log debug:

[2021-04-20 09:29:14] VERBOSE[14266] res_pjsip_logger.c: <— Received SIP request (786 bytes) from WS:172.18.10.51:6518 —>
[2021-04-20 09:29:14] DEBUG[14266] res_pjsip_transport_websocket.c: Request msg REGISTER/cseq=5112 (rdata0x7f39e80ff9a8) re-writing Contact URI from 0dtnbh94cpdq.invalid:0;transport=ws to 172.18.10.51:6518;transport=ws
[2021-04-20 09:29:14] DEBUG[14266] res_pjsip/pjsip_distributor.c: Could not find matching transaction for Request msg REGISTER/cseq=5112 (rdata0x7f39e80ff9a8)
[2021-04-20 09:29:14] DEBUG[14266] res_pjsip/pjsip_distributor.c: Taskprocessor overload on non-udp transport. Received:‘Request msg REGISTER/cseq=5112 (rdata0x7f39e80ff9a8)’. Responding with a 503.

But I really have no glue where to look beyond that.

A taskprocessor overload message would have occurred earlier. The debug message regarding not finding a matching transaction is fine to occur. And looking at the logs can only do so much. Reducing usage, eliminating usage of parts, that’s the best way to find what about your usage is causing it.

Ok. Thanks.

One last question, what exactly does “Max Depth” means, is it a cumulative number? Does it ever decrease?

Processor-------------Processed—In Queue—Max Depth—Low water—High water
stasis/pool-control-----8907598---------266---------1172-----------450----------500

Thank you very much for your time and your help.

It doesn’t decrease. It is the maximum number of queued items that has ever occurred while Asterisk is running. It means that at one point there were 1172 things waiting to be processed.

Right.

I’ll keep looking for it.

Thanks.