asterisk users - May 2020 - Asterisk 13.22.0 unstable on Azure Centos 7 & cannot encode .gsm files

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 '<token>', 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 at
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,



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200511/d2d726b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 76340 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200511/d2d726b0/attachment-0001.png>