I recently upgraded from 17.x to 18.3. Since the upgrade I’ve been observing occasional
“Exceptionally long voice queue length queuing to Local/number-id…”
It doesn’t happen all the time and as far as I can tell it doesn’t break anything either. I originate calls from node js , using one of the npm packages over AMI Manager and after successful result it gets sent to designated queue. When I receive this error, I check the queue “Show Queue QueueName” and the call is present awaiting to be answered. The ful line is
WARNING[578963][C-0001aed9]: channel.c:1086 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/numberDialed@queueName-00005288;1
I saw some similar issues reported and the most recent incident reported seems to have been fixed in v17x.
The message means that audio frames are queued up but the thread that should be reading them isn’t doing so, or isn’t doing so fast enough. A backtrace[1] would be needed.
Thanks for your reply. I’ve checked the link you’ve provided, which option would be the appropriate one to follow? It’s not a crashing issue , but also there is one thing. This is a high production live system. I would regret it if I broke something in the process.
The link I gave was for a deadlock which would be the one. Executing it will freeze Asterisk for a few seconds, it depends on usage and how much memory is in use. Otherwise without such a thing one can only guess vaguely. If it’s a highly used system, then a backtrace may not even be enough and it may be the result of that in some way and not a deadlock.
I get your point, but 3 days ago before performing the upgrade I had other issue but not this one. Those are gone now this one started. System is running on an 8 core 32gb ram dedicated server.
does this give any useful information ?
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 9349 99.7 0.0 65644 7224 ? R Apr23 3842:20 rasterisk r
root 9527 18.6 1.3 5460096 452300 ? Sl Apr23 719:26 /usr/sbin/asterisk -f -vvvg -c
cpu is not actually 100% centos8 reports per core so real 100% usage is actually 800% when yo urun the top command
Hi David, I coudnt understand your question. Could you give me an example? or anything I can do to provide more info. However, is this normal? it’s the first time I’m seeing two asterisk processes.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9349 root 20 0 65644 7224 6260 R 100.0 0.0 3902:11 asterisk
9527 root 20 0 5456596 451332 33608 S 0.3 1.4 723:04.80 asterisk
An example would be any setting of logging that caused the console output to scroll past a great deal faster than you could read it.
rasterisk is asterisk running as the console and it should only be consuming CPU when you are entering a command or it is displaying output. If you did have an excess amount of logging, it might well result in production threads being delayed.
Maybe I did something worng during upgrade or did not perform a step I should have. Just followed normal instructions I could find. Except I just realized that I did not perform any of the clean / dist-clean options.
restarted asterisk.service, seems better
but do you see anything wrong with below SS
in this order. Unless any additional steps necessary. This should keep old settings as well as spool(how about modules?) directory and other directories untouched . As the make dist-clean only removes “all files generated by make and configure” am I right?
I wouldn’t run make install or make config without first stopping the daemon. The best that can happen if you don’t do that, is that the old versions continue to run until a new shared library has to be loaded. The worst is that things start breaking immediately.
But after the upgrade it did flash a warning that those might not be compatible with the new version. So I went and replaced those with the v18 versions. I still suspec that since I did not perform the preliminary make clean / distclean , it probably re-written the whole configuration(while some old config may still be present) and this may be the source of the problem.
I will be testing this again tomorrow. However, as for the CPU usage of the processes rasterisk and asterisk , after service stop / start that seems to be OK now. I may need to re-do the whole(upgrading process) thing again
