[asterisk-users] How to debug this specific issue?
davies147 at gmail.com
Wed Aug 25 11:38:27 CDT 2010
On 25 August 2010 08:22, Matt Riddell <lists at venturevoip.com> wrote:
> On 25/08/10 7:20 PM, Tilghman Lesher wrote:
>>> I really thought that the canary should have sounded if Asterisk got in
>>> a loop - or maybe that only happens with high priority?
>> The canary only runs in high priority mode, and it's only able to do anything
>> if high priority scheduling is the culprit. If it's something else, like
>> memory swapping, there's nothing the canary can do to fix that.
> Aha, explains why I've never seen the canary die :D
...and yes, I was running in high priority mode - I thought I was
turning it off for testing, but looks like I left the setting in
asterisk.conf so leaving '-p' off the command line was making no
I believe the issue was actually with the devicestate thread. It was
trying to update state on a locked channel, and was trying to grab the
lock so regularly that it caused asterisk to grab lots of CPU cycles
(because of -p mode) The lock was not released because it was waiting
on a database write, which was being done by a lower priority external
process that was getting no time scheduled to it.
The database write is a local hack to record some extra call data - I
changed it to occur after the locks are released as I should have done
in the first place.
18.104.22.168 does not seem to have quite the same issue - It recovers
after the usual 200 lock attempts and gets on with life much more
happily. I cannot see any changes between 22.214.171.124 and 126.96.36.199 that
would have improved this behaviour.
More information about the asterisk-users