LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2001, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Mon, 14 May 2001 13:16:17 -0700
Reply-To:     kmself@IX.NETCOM.COM
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;
protocol="application/pgp-signature";

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 significantly.

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 <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org


[application/pgp-signature]


Back to: Top of message | Previous page | Main SAS-L page