HI ,
i am exploring asterisk 22.8.2 for my PBX system to upgrade from Asterisk 16.
But when i am hitting CPS >2 asterisk struck and stop recieving any new invite also no command is running on the asterisk.
My running asterisk in conatiner with 16vcpu and 24 Gb RAM.I am using AMI and ARI technology where on every call new ami connection is making by my Code.
In asterisk 16 we didn’t face this problem but voice crack issue observed on regular basis.
Kindly help me to reslove the problem
The “new AMI connection per call” is almost certainly your problem. This worked in Asterisk 16 but will freeze Asterisk 22 under load because the internal event architecture changed significantly between those versions.
Here’s what’s happening: Asterisk 22 routes AMI events through the Stasis message bus. Every AMI connection subscribes to this bus. Every channel event (new call, state change, hangup, DTMF, etc.) gets dispatched to every connected AMI session. So if you’re creating a new AMI connection per call at 2 CPS, after 30 seconds you have 60+ AMI connections, and every single channel event is being copied and dispatched 60+ times.
The `stasis/m:manager:core` task processor falls behind, the queue fills up, and because PJSIP also uses Stasis internally for its own messaging, new SIP INVITEs can’t be processed either. CLI freezes too because it goes through the same internal message system.
Check it next time it happens (if the CLI is still partially responsive):
```
core show taskprocessors
```
Look for non-zero “In Queue” values, especially on `stasis/m:manager:core`. If those queues never drain, that’s your bottleneck. You can also check from outside:
```
asterisk -rx ‘core show taskprocessors’ | grep -v ’ 0$’
```
The fix is to stop creating AMI connections per call. Use a persistent connection pool instead — open 2-4 AMI connections at startup, keep them alive, multiplex your call control through them. Filter events by channel name on your application side rather than subscribing/unsubscribing per call.
If you’re using ARI (you mentioned both AMI and ARI), same principle applies. ARI WebSocket connections also subscribe to Stasis. Don’t create a new WebSocket per call.
Quick things to also check:
```
# file descriptor count for the asterisk process
ls /proc/$(pidof asterisk)/fd | wc -l
# TCP connection state on AMI port
ss -tan state time-wait | grep :5038 | wc -l
```
If you see hundreds of TIME_WAIT sockets on port 5038, that confirms rapid AMI connection churn. Your OS is still cleaning up old connections while new ones pile up.
On a system we run with similar volume, we have 16 persistent AMI connections handling tens of thousands of calls per day with no issues. The key is connection reuse, not connection-per-call.