On 25 August 2010 08:22, Matt Riddell <li...@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 difference *sigh* 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. 1.6.2.11 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 1.6.2.10 and 1.6.2.11 that would have improved this behaviour. Cheers, Steve -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users