The 'stasis/pool-control' task processor queue reached 500 scheduled tasks again

Hi,

I’ve seen in my log the dreaded “The ‘stasis/pool-control’ task processor queue reached 500 scheduled tasks again.” pop up for some times.

It doesn’t seem to have any operational impact, but I’d still like to diagnose it: maybe there is an impact that is not reported to me, or maybe the impact will come later…

I investigated it a bit, and it seems to happen in batches when calls are inbound to queues.

core show taskprocessors

shows that besides stasis/pool-control, there is only one line that breaches the high water:

stasis/m:manager:core-00000007                                           10485350          0       3344       2700       3000

There are also a few that approach or breach the low water:

stasis/p:manager:core-00000154                                           10461367          0        469        450        500
stasis/p:manager:core-00000d39                                            9052240          0        446        450        500
stasis/p:manager:core-00001340                                            8216147          0        448        450        500
stasis/p:manager:core-0000136b                                            8215680          0        450        450        500
stasis/p:manager:core-00002707                                            5945661          0        432        450        500
stasis/p:manager:core-00002732                                            5945359          0        432        450        500
stasis/p:manager:core-00002735                                            5945170          0        432        450        500
stasis/p:manager:core-00002bbd                                            5483902          0        432        450        500
stasis/p:manager:core-00002d80                                            5300301          0        432        450        500
stasis/p:manager:core-000031bc                                            4841189          0        432        450        500
stasis/p:manager:core-000031e9                                            4840617          0        432        450        500
stasis/p:manager:core-000032a9                                            4771588          0        432        450        500
stasis/p:manager:core-000036c1                                            4203970          0        432        450        500
stasis/p:manager:core-00003760                                            4152879          0        432        450        500
stasis/p:manager:core-000044f4                                            2128590          0        324        450        500
stasis/p:manager:core-00004ca4                                            1208520          0        320        450        500
stasis/p:manager:core-00004ccf                                            1207993          0        320        450        500
stasis/p:manager:core-00004cfa                                            1207503          0        320        450        500
stasis/p:manager:core-00004d25                                            1207047          0        320        450        500
stasis/p:manager:core-00004d50                                            1206373          0        320        450        500
stasis/p:manager:core-00004d7b                                            1205880          0        320        450        500
stasis/p:manager:core-00004da6                                            1205294          0        320        450        500
stasis/p:manager:core-00004dd1                                            1204772          0        320        450        500
stasis/p:manager:core-00004e1c                                            1177224          0        320        450        500

We have a few pjsip phones, all behind queues, and a bunch of Sangoma Talk smartphones and desktops behind those queues or directly reachable.

I have a small python script that uses GitHub - VoIPGRID/cacofonisk: Who's calling? · GitHub to monitor call events via AMI to feed them to our crm, but as the error only pops up when the queues are used, I’d think that it’s not related.

What can I do to diagnose this further ?

Thanks

It happens when lots of tasks are queued at the same time and the stasis threadpool is trying to grow/shrink/wakeup/manage threads.

Recent versions of Asterisk no longer have it[1], and have other performance improvements.

[1] https://www.asterisk.org/taskpool-a-hunch-turned-performance-improvement/

ok I see that asterisk is waiting to be upgraded to 22.10.1 on my system, which should “magically” solve this issue if I understand correctly.

I’ll do that asap, thanks.