Playback ivr file slowly, when many concurrent calls are in system and they are hearing that ivr file in the same time

dear friends
when i have some concurrent calls about 25 or more and all of them are listening ivr file, ivr file plays slowly and not ok, like you speed down the file,
for example in first seconds of file , sound is ok but suddenly it become very slow and again ok and after that so slow (that i cant even understand what it says)

it’s very bad,
Background and Playback and Read , all of them plays file with this problem.
do you think asterisk is craching ?!!

there is no exact log and no cpu or memory load. every things sounds good execpt playing ivr.

can some body help me to solve the problem.

What is your hardware?
What is the output of channelstats?
Do your sound files need transcoding?

You need to be more precise in case you expect someone to help you.

hp server g9 elff
10 core cpu
10 gig ram

is “channelstats” a asterisk command ??

how can i find that my sound needs transcoding?

Compare the file format used for the sound with that used for telephony. DAHDI channels will be alaw or ulaw.

i use asterisk files like demo-congrats and files in en/ folder , but problem exist with these files too.
i thinks problem is not about file and its format or codec.

how can i monitor the exact problem?

Transcoding is relevant because it can impose a high CPU load.

You need to use tools like “top” and the more technical system monitoring tools, from the OS, to work out which resources is running out.

Can you confirm this is NOT a virtual machine?

no resources consume abnormally.

its a virtual machine on hp g9 server with 10core cpu and 10gig memory.

how can i check transcoding or stop it. is there any command to check it out.

i run top but nothing. my cpu load is below 50%

please guide me dears

i think it’s CDR that is making voice to be slow down,
how can i monitor CDR threads or any concept concerning to this issue?

I can’t imagine how CDR processing would lock out audio playout for significant periods, other than CPU, memory, disk, or network resource contention. However, they way would go further woudl be to rebuild with no optimise, debug threads, and probably better back traces, then use core show locks to find out what the playout code was waiting for, and possibly also more invasive low level debugging techniques.

I would seriously want to consider whether this was a vitualisation problem was, unless you take steps to avoid it, system time doesn’t track real time, over shorter periods, in vrtual machines and you have to consider resource usage, in particular disk arm usage, across all hte guests.

acctually we have another problems,
CDR raised with delay about 20 minutes :flushed:
i cant check status of a call because cdr table update after 20 minutes or more, for each call.
call at 1:30pm doesn’t have CDR till 1:59pm
i dont know why CDR proccessing is so slow,

-another problem is in setting channel variable:
i set a channel variable at 2:30pm in dialplan , but i take it from ami event (setvar ) at 2:38pm with delay of 8 minutes .

i think slowness in ivr sound, related to above problems too.

rebuilding with no optimise, debug threads, and back traces, can make any problem for my system ???
as it’s running and many important calls are on it.

i found that asterisk is consuming about 90% of my memory :astonished:
about 9.3 of 10 gig !!!
but why?
what is it doing!!!

Can you confirm that this is the figure from ps -l, as the way that Linux (and NT) works means that it is normal for the overall OS memory usage ot show a figure iike that, although, in the case of Linux, the standard tool also shows a figure without cache and buffer use.

If it really is showing in ps -l, you have a memory leak and you need to try and work out what causes it to grow, and, if possible, by how much it grows.

WIth virtualisation, it is possible you are getting page ins, even though you aren’t using an OS swap file.

I am also facing slow CDR processing issue and searching solution since long time.

However, not able to find any solution till now.

Regards,
Dinesh

Quite likely to be related. What CDR backend are you using, and if a database, which database library?

Yes, channelstats is an Asterisk console command. It comes in two flavors: “sip show channelstats” and “pjsip show channelstats”.

The hardware should be more than enough, unless it is a running as a virtualization server and you’ve got a vm with1 GB of RAM, a misconfigured NIC, and a single processor.

You could increase the verbosity to 3 in the console, play a file and send us the output. Your problem should not occur on a correctly configured Asterisk server.

i just playback a simple file, but again slow voice of file :

Executing [49763430@check:1] Playback("OOH323/router-218", "demo-congrats") in new stack
       > 0x7f8bc298cda0 -- Strict RTP learning after remote address set to: 10.1.10.11:19932
       > 0x7f8bc298cda0 -- Strict RTP learning after remote address set to: 10.1.10.11:19932
       > 0x7f8bc298cda0 -- Strict RTP switching to RTP target address 10.1.10.11:19932 as source
    -- <OOH323/router-218> Playing 'demo-congrats.gsm' (language 'en')

my server is on a esx 6.5 - hp server g9

out put of channelstat :

asterisk -rx "sip show channelstats"
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.1.10.254      024d296672d  00:00:11 0000000386  0000000000 ( 0.00%) 0.0000 0000000282  0000000001 ( 0.35%) 0.0024
10.1.10.254      15e9287258d  00:06:05 0000018002  0000000098 ( 0.54%) 0.0000 0000017895  0000000035 ( 0.20%) 0.0015
10.123.101.177   isbclh6ukfs  00:05:23 0000016088  0000000053 ( 0.33%) 0.0000 0000015440  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcieq6jfv  00:00:52 0000002559  0000000023 ( 0.89%) 0.0000 0000002259  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcuakl6id  00:00:23 0000001104  0000000008 ( 0.72%) 0.0000 0000000794  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbc6gkfgvl  00:00:29 0000001415  0000000006 ( 0.42%) 0.0000 0000001053  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcdsdkvhu           0000000603  0000000016 ( 2.58%) 0.0000 0000000360  0000000000 ( 0.00%) 0.0113
10.123.101.177   isbcuhi6iku           0000001967  0000000004 ( 0.20%) 0.0000 0000001558  0000000000 ( 0.00%) 0.0031
10.1.10.254      74212d3f385  00:02:21 0000006853  0000000034 ( 0.49%) 0.0000 0000006757  0000000151 ( 2.23%) 0.0009
10.123.101.177   isbcqlqkavl  00:01:11 0000003508  0000000007 ( 0.20%) 0.0000 0000002714  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcqeg6rh6  00:02:23 0000007092  0000000056 ( 0.78%) 0.0000 0000006328  0000000001 ( 0.02%) 0.0002
10.1.10.254      4665f7d8403  00:07:21 0000021506  0000000177 ( 0.82%) 0.0000 0000021491  0000000000 ( 0.00%) 0.0007
10.1.10.254      4f6160dc6c8  00:00:36 0000001600  0000000006 ( 0.37%) 0.0000 0000001519  0000000001 ( 0.07%) 0.0010
10.123.101.177   isbcqa6sghq           0000004993  0000000010 ( 0.20%) 0.0000 0000003956  0000000000 ( 0.00%) 0.0230
10.123.101.177   isbcgduvqrv  00:00:48 0000002384  0000000008 ( 0.33%) 0.0000 0000001831  0000000000 ( 0.00%) 0.0002
10.1.10.254      4b4506e05d7  00:01:10 0000003289  0000000017 ( 0.51%) 0.0000 0000003219  0000000001 ( 0.03%) 0.0006
10.123.101.177   isbclkrsuvi  00:00:27 0000001351  0000000008 ( 0.59%) 0.0000 0000001008  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbckhvaafi           0000002829  0000000005 ( 0.18%) 0.0000 0000002213  0000000000 ( 0.00%) 0.0068
10.123.101.177   isbcehelkah  00:00:07 0000000315  0000000000 ( 0.00%) 0.0000 0000000214  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcghivkua  00:00:54 0000002711  0000000013 ( 0.48%) 0.0000 0000002470  0000000000 ( 0.00%) 0.0003
10.1.10.254      75c6731f14a  00:04:27 0000013091  0000000073 ( 0.55%) 0.0000 0000013038  0000000022 ( 0.17%) 0.0009
10.1.10.254      719892a54b0           0000005504  0000000031 ( 0.56%) 0.0000 0000005461  0000000149 ( 2.73%) 0.0332
10.123.101.177   isbckkdqhau  00:00:10 0000000472  0000000005 ( 1.05%) 0.0000 0000000305  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcqgjkeaa  00:00:20 0000000999  0000000010 ( 0.99%) 0.0000 0000000716  0000000000 ( 0.00%) 0.0005
10.1.10.254      270c521a6b1  00:00:06 0000000000  0000000000 ( 0.00%) 0.0000 0000000000  0000000000 ( 0.00%) 0.0000
10.123.101.177   isbcslaajvf  00:07:39 0000022804  0000000122 ( 0.53%) 0.0000 0000022343  0000000001 ( 0.00%) 0.0002
10.1.10.254      16bd11ff496  00:01:23 0000003694  0000000013 ( 0.35%) 0.0000 0000003626  0000000089 ( 2.45%) 0.0013
10.123.101.177   isbciiuviae  00:07:02 0000020918  0000000152 ( 0.72%) 0.0000 0000020279  0000000002 ( 0.01%) 0.0002
10.123.101.177   isbcseghrsf  00:00:15 0000000730  0000000007 ( 0.95%) 0.0000 0000000489  0000000000 ( 0.00%) 0.0002
10.1.10.254      5209c186544  00:01:56 0000005459  0000000012 ( 0.22%) 0.0000 0000005385  0000000011 ( 0.20%) 0.0006
10.123.101.177   isbc6siuhqj  00:02:39 0000007878  0000000052 ( 0.66%) 0.0000 0000007480  0000000000 ( 0.00%) 0.0003
10.1.10.254      798704e85a0  00:00:31 0000001158  0000000008 ( 0.69%) 0.0000 0000001088  0000000001 ( 0.09%) 0.0009
10.123.101.177   isbcaihkkda  00:03:01 0000009002  0000000036 ( 0.40%) 0.0000 0000007953  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcsjjhjee           0000006044  0000000020 ( 0.33%) 0.0000 0000005760  0000000000 ( 0.00%) 0.0016
10.123.101.177   isbchlsrfqg  00:00:38 0000001865  0000000005 ( 0.27%) 0.0000 0000001574  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcgdgldds  00:01:16 0000003846  0000000012 ( 0.31%) 0.0000 0000002962  0000000000 ( 0.00%) 0.0003
10.1.10.254      71dcf77911c  00:02:32 0000007093  0000000034 ( 0.48%) 0.0000 0000006978  0000000188 ( 2.69%) 0.0014
10.123.101.177   isbcqugfjra  00:01:36 0000004788  0000000016 ( 0.33%) 0.0000 0000004547  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcdiguefg  00:00:26 0000001277  0000000007 ( 0.55%) 0.0000 0000000935  0000000000 ( 0.00%) 0.0003
10.1.10.254      1719a2dd1f1  00:00:47 0000002266  0000000012 ( 0.53%) 0.0000 0000002193  0000000000 ( 0.00%) 0.0011
10.123.101.177   isbchsqg6ef  00:07:19 0000021850  0000000134 ( 0.61%) 0.0000 0000021299  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcafah6kj  00:00:32 0000001606  0000000005 ( 0.31%) 0.0000 0000001164  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcdhdvs6i  00:00:08 0000000377  0000000000 ( 0.00%) 0.0000 0000000224  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbclduqash  00:02:13 0000006653  0000000025 ( 0.37%) 0.0000 0000005711  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcseuqjjs  00:03:28 0000010331  0000000043 ( 0.41%) 0.0000 0000009587  0000000000 ( 0.00%) 0.0003
10.1.10.254      12dd7f626ea  00:01:25 0000003951  0000000012 ( 0.30%) 0.0000 0000003872  0000000001 ( 0.03%) 0.0010
10.1.10.254      401493ec0ea  00:00:14 0000000433  0000000000 ( 0.00%) 0.0000 0000000284  0000000022 ( 7.75%) 0.0005
10.123.101.177   isbcvsf6igg           0000001780  0000000001 ( 0.06%) 0.0000 0000001375  0000000000 ( 0.00%) 0.0014
10.123.101.177   isbcgqvefu6           0000000315  0000000000 ( 0.00%) 0.0000 0000000192  0000000000 ( 0.00%) 0.0175
10.123.101.177   isbcradlvl6  00:00:12 0000000587  0000000008 ( 1.34%) 0.0000 0000000374  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbcrhhqrud  00:03:08 0000009330  0000000048 ( 0.51%) 0.0000 0000008180  0000000000 ( 0.00%) 0.0002
10.123.101.177   isbcuqdilik  00:00:07 0000000337  0000000000 ( 0.00%) 0.0000 0000000214  0000000000 ( 0.00%) 0.0003
10.123.101.177   isbchqvvegg  00:00:55 0000002698  0000000020 ( 0.74%) 0.0000 0000002041  0000000000 ( 0.00%) 0.0003
53 active SIP channels

just in Master.conf
and to a Mssql server with odbc driver

i record my inbound calls from the first of ivr with mixmonitor()
but i dont use stopmixmonitor() at the end of call (in h exten)
is it make any problem?
for example some extra mixmonitor threads in asterisk stays and make bad performance for asterisk in some advanced senario(using agi -ami - complicated dialplan - many variable set in channel - some external api calling with curl in phpagi & …)

ivr plays slowly and cdr process with over 20min delay, file recording is not ok (bad recordind),