[Asterisk-Users] re: call "load balancing"

[Tzafrir Cohen]

Hi

Kind of late reeply. Still it mat be useful for others.

On Wed, Aug 10, 2005 at 05:07:42PM +0100, Kevin Walsh wrote:
> Joseph [syscon at interbaun.com] wrote:
> > Don't forget to experiment with "nice" to increase priority of for
> > Asterisk.
> > By default asterisk run with priority "0" same as apache and any other
> > applications.

Actually, "nice level" is not exactly a priority. It is mearly a
priority bonus. More on that below.

There are two ways I can think of:

1. use nice in the command that runs asterisk. If using
start-stop-daemon, Be sure to leave the --exec parapeter in tact and add 
--startas.

Another option is to use renice:

  renice -10 -u asterisk

or:

  renice -15 -p `cat /var/run/asterisk/asterisk.pid`

> > We run a web-server on the same machine as asterisk and increasing
> > "nice" for Asterisk to -15 helped a lot.
> >
> You don't need to mess about with nice.  Just run Asterisk with realtime
> priority;  Use the -p switch when you start the Asterisk daemon.

-p puts Asterisk in real-time priority. This is much more aggressive
than the "nice level".

When a number of processes are ready to run, the system's scheduler
needs to choose which of them will run. A common technique on most OSes
is to keep a number that indicates how much is the process entitled to
use the CPU. Whenever the process uses the CPU the number is increased (at
least in unix) and only slowly reduced over time.

A "nice level" changes that "base priority". It puts the process still on
the smae playing field with the other processes, but only gives it a
small boost.


Real-time priority[1] is something different: if the schduler sees
proccesses with real-time priorities that have something to do, then
they will do it. This is generally what we would want, because we
would want Asterisk to handle sound fast.

However: this means that a bug that makes Asterisk consume 100%CPU will
practically stall the system. The system will still answer pings and
open sockets, because that is done in the kernel. But nothing further
will be done.

/methinks are there threads of Asterisk that don't need to run in
real-time priority? Are there parts of Asterisk that don't need to run
in in real-time priority that could be moved to separate
"lower-priority" threads? Call this "priv-separation" :-) .

[OK, OK, don't ask -devel questions about post-1.2 on the -users list. I
know :-) ]

[1] Not to be confused with real-time configuration query from an
external source, which is the normal meaning of "real-time" in Asterisk
nowadays.

-- 
Tzafrir Cohen         | tzafrir at jbr.cohens.org.il | VIM is
http://tzafrir.org.il |                           | a Mutt's  
tzafrir at cohens.org.il |                           |  best
ICQ# 16849755         |                           | friend