To: Alan Stange <stange@rentec.com>
Cc: Luke Lonergan <llonergan@greenplum.com>,  Greg Stark <gsstark@mit.edu>,
	Dave Cramer <pg@fastcrypt.com>,  Joshua Marsh <icub3d@gmail.com>,
	pgsql-performance@postgresql.org
Subject: Re: Hardware/OS recommendations for large databases (
References: <BFA48F15.14182%llonergan@greenplum.com>
	<437FE2E4.5040600@rentec.com>
In-Reply-To: <437FE2E4.5040600@rentec.com>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 20 Nov 2005 09:22:41 -0500
Message-ID: <87y83jo0um.fsf@stark.xeocode.com>
Lines: 34
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Alan Stange <stange@rentec.com> writes:

> > Iowait is time spent waiting on blocking io calls.  As another poster
> > pointed out, you have a two CPU system, and during your scan, as predicted,
> > one CPU went 100% busy on the seq scan.  During iowait periods, the CPU can
> > be context switched to other users, but as I pointed out earlier, that's not
> > useful for getting response on decision support queries.

I don't think that's true. If the syscall was preemptable then it wouldn't
show up under "iowait", but rather "idle". The time spent in iowait is time in
uninterruptable sleeps where no other process can be scheduled.

> iowait time is idle time. Period.   This point has been debated endlessly for
> Solaris and other OS's as well.
> 
> Here's the man page:
>               %iowait
>                      Show  the  percentage  of  time that the CPU or CPUs were
>                      idle during which the system had an outstanding disk  I/O
>                      request.
> 
> If the system had some other cpu bound work to perform you wouldn't ever see
> any iowait time.  Anyone claiming the cpu was 100% busy on the sequential scan
> using the one set of numbers I posted is misunderstanding the actual metrics.

That's easy to test. rerun the test with another process running a simple C
program like "main() {while(1);}" (or two invocations of that on your system
because of the extra processor). I bet you'll see about half the percentage of
iowait because postres will get half as much opportunity to schedule i/o. If
what you are saying were true then you should get 0% iowait.

-- 
greg