Asterisk 13.22.0 Unstable On Azure CentOS 7 & Cannot Encode .gsm Files

Home » Asterisk Users » Asterisk 13.22.0 Unstable On Azure CentOS 7 & Cannot Encode .gsm Files
Asterisk Users No Comments

——=_NextPart_001_002B_01D6278F.E4200A80
Content-Type: text/plain;
charset=”us-ascii”
Content-Transfer-Encoding: 7bit

Hi all,

I’m running a CentOS 7 instance in Azure with Asterisk 13. The CentOS VM has
24GB of RAM and identifies the CPU as Intel(R) Xeon(R) CPU E5-2660 0 @
2.20GHz.

This is a virtual copy of a physical CentOS 7 machine which has 16GB of RAM
and the physical CPU identifies itself as the same in /proc/cpuinfo.

I’m running up to 150 to 200 callers without problems on the physical machine, usually have about 320 to 370 channels open simultaneously.

The physical box encodes to .gsm for recordings.

The virtual CentOS 7 box keeps crashing with the same dialplan, at around
100 callers (200+- channels).

Symptoms are that these will appear in the CLI on the virtual Asterisk instance:

May 11 11:54:32 asterisk: [May 11 11:54:32]
#033[1;31mWARNING#033[0m[8830][C-00000d02]:
#033[1;37mtaskprocessor.c#033[0m:#033[1;37m895#033[0m
#033[1;37mtaskprocessor_push#033[0m: The
‘subp:ast_channel_topic_all-0000064d’ task processor queue reached 500
scheduled tasks again.

May 11 11:54:32 asterisk: [May 11 11:54:32]
#033[1;31mWARNING#033[0m[8830][C-00000d02]:
#033[1;37mtaskprocessor.c#033[0m:#033[1;37m895#033[0m
#033[1;37mtaskprocessor_push#033[0m: The
‘subp:ast_channel_topic_all-00000683’ task processor queue reached 500
scheduled tasks.

May 11 11:54:32 asterisk: [May 11 11:54:32]
#033[1;31mWARNING#033[0m[8830][C-00000d02]:
#033[1;37mtaskprocessor.c#033[0m:#033[1;37m895#033[0m
#033[1;37mtaskprocessor_push#033[0m: The
‘subp:ast_channel_topic_all-00000673’ task processor queue reached 500
scheduled tasks again.

May 11 11:54:32 asterisk: [May 11 11:54:32]
#033[1;31mWARNING#033[0m[8773][C-00000cfc]:
#033[1;37mtaskprocessor.c#033[0m:#033[1;37m895#033[0m
#033[1;37mtaskprocessor_push#033[0m: The
‘subp:ast_channel_topic_all-00000517’ task processor queue reached 500
scheduled tasks again.

May 11 11:54:32 asterisk: [May 11 11:54:32]
#033[1;31mWARNING#033[0m[8755][C-00000cf9]:
#033[1;37mtaskprocessor.c#033[0m:#033[1;37m895#033[0m
#033[1;37mtaskprocessor_push#033[0m: The
‘subp:ast_channel_topic_all-00000645’ task processor queue reached 500
scheduled tasks again.

Mixed with 100s of lines of these:

May 11 11:48:31 asterisk: [May 11 11:48:31]
#033[1;31mWARNING#033[0m[115959][C-00000937]:
#033[1;37mast_expr2.fl#033[0m:#033[1;37m470#033[0m
#033[1;37mast_yyerror#033[0m: ast_yyerror(): syntax error: syntax error, unexpected ‘‘, expecting $end; Input:

Then there will be a few 100 of these:

[May 11 12:10:33] WARNING[63930]: pbx.c:4548 increase_call_count: Maximum loadavg limit of 50.000000 load exceeded by ‘Local/3155@local-00002d4e;2’
(currently 50.190000)!

And then the virtual Asterisk instance will go into a state where no call hangs up and no new calls can be made via the AMI, calls to the AMI just being indefinitely suspended and not receiving a response.

Neither can the virtual asterisk be shut down using a “core stop now” or
“core stop gracefully”, and it doesn’t respond to kill -1, I have to kill -9
the PID.

The virtual equivalent CentOS 7 Asterisk 13.22.0 machine with 8GB more RAM
than the physical cannot nearly handle even half of what the real-metal equivalent machine handles, without any of the above CLI errors and warnings.

Also, the virtual asterisk encodes corrupt .gsm files, none it produces are readable or playable by other Asterisk instances and not by VLC.

Is there anything I can do about the crashes – except get off Azure? I’ve bypassed the corrupt .gsms by encoding to .wav and hooking into the recording hook that ther mixmonitor app offers.

-ANY- ideas?

Thanks,

——=_NextPart_001_002B_01D6278F.E4200A80
Content-Type: text/html;
charset=”us-ascii”
Content-Transfer-Encoding: quoted-printable