On one Asterisk instance, I’ve had once the warning bellow.
WARNING taskprocessor.c: The ‘pjsip/distributor-000000c2’ task processor queue reached 500 scheduled tasks.
Shortly after this warning, new calls could not come in until system recovery.
This system does use CDR but does not use Stasis, AMI, CEL and others.
From , it seems you “need to adjust the thread pool parameters” when you’re hit by this task processor queue warning.
How should you exactly adjust the thread pool parameters to double task processor queue size, for instance ? Is there simple x10 factor between thread_pool_max_size and task processor queue size ?
 Asterisk Task Processor Queue Size Warnings ⋆ Asterisk
This would mean that the PJSIP distributor itself is backed up. Are you using realtime? And the options don’t control the task processor queue size directly, it controls how spread out things can be.
I’m not using realtime.
I see two non-exclusive strategies:
- lower resource consumption unloading unused modules: this shouldn’t change the queue size but lower probability for the upper limit to be hit,
- increase queue size changing some “indirect” settings (those changing how things are spread out).
I’m tempted to favor strategy 1.
How can I demonstrate I’m on the right path ?
Counting the lines show by “core show taskprocessors” when N simultaneous calls are passing through Asterisk ?
That will tell you the usage of taskprocessors, yes.
Unused modules shouldn’t be using the queues, so I don’t see how (1) would make any difference.
You really need to find out why tasks are not being processed as fast as they are being created. The question about realtime was guessing at delayed responses from databases, but you should also look for other APIs (although I suspect that Joshua’s noting the PJSIP distributor as the problem is probably suggesting it isn’t something like an AMI event backlog).
I would assume the ultimate way of changing the limits, is to change the source code DEFINEs and recompile. As I understand it these are limits beyond which mitigation strategies, like load shedding, are started, not actual hard limits on the queue sizes.
Thanks for replying.
Given both answers, I think I’ll build a new Asterisk with I’ll experiment both strategies: removing modules et changing thread pool settings within PJSIP.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.