From owner-freebsd-stable Fri Mar 9 9:26:27 2001 Delivered-To: freebsd-stable@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 6482E37B718 for ; Fri, 9 Mar 2001 09:26:24 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id JAA29975; Fri, 9 Mar 2001 09:26:18 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda29973; Fri Mar 9 09:26:10 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f29HQ5Y60935; Fri, 9 Mar 2001 09:26:05 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdy60933; Fri Mar 9 09:25:26 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f29HPQR31493; Fri, 9 Mar 2001 09:25:26 -0800 (PST) Message-Id: <200103091725.f29HPQR31493@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdc31485; Fri Mar 9 09:24:46 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: FreeBSD Stable Cc: Mikhail Teterin Subject: Re: load stays at 1 on an idle machine In-reply-to: Your message of "Fri, 09 Mar 2001 11:44:35 EST." <20010309114435.B45561@ohm.physics.purdue.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Mar 2001 09:24:46 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010309114435.B45561@ohm.physics.purdue.edu>, Will Andrews writes: > > --AXo2lOxbfudqq8ta > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Mar 09, 2001 at 10:39:53AM -0500, Mikhail Teterin wrote: > > I was running a single instance of SETI@Home, when I observed the load > > of 2. I stopped seti and the load went down to one. It stays there for > > about 20 hours already. The machine is idle: > >=20 > > last pid: 1886; load averages: 1.00, 1.00, 1.00 up 0+20:36:36 10= > :33:11 > > 16 processes: 1 running, 15 sleeping > > CPU states: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% = > idle > > Mem: 7136K Active, 20M Inact, 9024K Wired, 56K Cache, 22M Buf, 88M Free > > Swap: 256M Total, 256M Free > >=20 > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > > [....] > > top(1) doesn't show all stats relevant to the load average. Check > vmstat/systat/iostat/netstat/etc. Besides, the load average is a > worthless metric if you ask me. Load average, the average run queue length over a period of time, is a good indicator of whether you need to look elsewhere for problems. I usually look at the load average first. Some OLTP applications behave poorly with a load average < 1.0, e.g. for these applications CPU > 80% is usually bad. Other applications can tolerate higher load before performance sucks. Load average is O/S dependent. For example load average > 1.5 on Tru64-UNIX systems generally affects performance, while most of the applications on the Sun systems I manage can handle load averages < 3.0 quite nicely. With the workloads I run on the small farm of FreeBSD systems my team manages, we can push the load average to 4 or 5 before I begin to notice a degradation in response. Load average is a good INITIAL temperature gauge when you understand the system and the application running on a particular system. Beyond that you need to drill down further. IMO, load averages > 1.0 per CPU, e.g. 3.0 on a 3 CPU system, affects throughput (not the same as response time). If I may digress, scan rate on FreeBSD and Tru64-UNIX systems is a somewhat meaningless indicator of memory utilisation, while page-outs and to a lesser extent page-ins are indicative of memory shortage. While on the other hand Solaris scan rate and page reclaims is an excellent indicator of when to purchase more memory. My point is that one cannot use just one metric to analyse the performance of a system and hence recommend the purchase of hardware upgrades. The metrics used to analyse a system are not the same across platforms. A number of factors need to be taken into account, not the least of which are the O/S, hardware platform, and application. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message