Date: Mon, 14 May 2001 13:16:17 -0700
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Karsten M. Self" <kmself@IX.NETCOM.COM>
Subject: Re: Unix performance question
In-Reply-To: <3B003171.71C6@virgin.net>; from
roland.rashleigh-berry@VIRGIN.NET on Mon, May 14,
2001 at 08:26:41PM +0100
Content-Type: multipart/signed; micalg=pgp-sha1;
on Mon, May 14, 2001 at 08:26:41PM +0100, Roland (roland.rashleigh-berry@VIRGIN.NET) wrote:
> Suppose you have a lot of SAS jobs running at the same time on Unix.
> Let's say the long-running ones are set to a low CPU dispatching
> priority and there is no problem with memory or disks being too busy
> and the processors on average are running at 45%. Why on earth would
> it run slow as a dog for all the SAS users? Any ideas?
Qualify and quantify your statements. I strongly recommend:
Mike Loukides, _System Performance Tuning_, O'Reilly & Associates,
©1990, Cambridge, MA. ISBN: 0-937175-60-9
Despite the age, fundamentals of performance tuning haven't changed
What is "slow as a dog" and how are you assessing this? Are your jobs
running more slowly when run in parallel than when run serially? How
are you asessing CPU, disk I/O, and memory contention? How have you
configured your system, particularly the disk subsystems? Is network
access to storage involved?
It would also help to specify the Unix vendor as system monitoring tools
vary somewhat by platform. In general, top, ps, and a memory monitoring
utility (varies: free, mem, vmstat are common ones) will be your
friends. Critical data include disk throughput and the number of jobs
blocked waiting for I/O.
Prioritizing jobs with nice will often fail spectacularly in producing
any reasonable results when I/O contention is a bottleneck. 'nice' is
more useful for rationalizing CPU-bound processes.
Karsten M. Self <email@example.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal