[asterisk-users] Is there real benefits on a SMP machine for Asterisk?

Tilghman Lesher tilghman at mail.jeffandtilghman.com
Fri Oct 12 12:49:16 CDT 2007


On Friday 12 October 2007 11:10:02 Gordon Henderson wrote:
> On Fri, 12 Oct 2007, Tilghman Lesher wrote:
> > On Friday 12 October 2007 10:29:24 Philipp Kempgen wrote:
> >> Atis Lezdins wrote:
> >>> I have 8-core system that has web interface + sql + java + some other
> >>> stuff running, and at 30 simultenous calls i get loadavg maximum of 3.
> >>
> >> I wouldn't be too happy about a system with a
> >> loadavg of 3.
> >
> > I dunno, 3 wouldn't be terrible on a 4 processor or 8 processor system,
> > which isn't getting to be nearly as rare as it once was.
>
> Don't get too hung-up on load average under Linux. It's not always
> indicative of the real "load" on the machine, it merely indicates the
> number of processes running, or avalable to run - so if a process is
> waiting on IO, it's 'running' and will get counted. I've seen servers (non
> asterisk) with huge load averages but ones which were still usable because
> the processes were waiting on IO from a slow device, (eg. remote NFS
> mounts) so there was plenty of CPU left for computational tasks, etc.
>
> So 3 threads reading or writing to/from a TDM card might well spend most
> of their time waiting for the IO to complete (clock in/out the A/D, A/D
> convertors for example), give a load avg. of 3, yet the CPU should be
> avalable for other tasks like shoveling RTP data over Ethernet for
> example...

Are you saying that Linux makes no differentiation between long and short
wait states?  That would be a fairly major abrogation of the spec.

I do know of a legal way (under the definition) to drive a load average
higher:  simply release the processor resource prematurely with either a
usleep(1) or a sched_yield().  The definition of load average depends
implicitly upon a process using its entire timeslot on the processor; if a
process does significantly less, the load average will rise without a
corresponding increase in actual CPU work.

-- 
Tilghman



More information about the asterisk-users mailing list