Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread mudfoot
; > Thanks, > > Anjan > > _ > > From: Woody Woodring [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 2:30 PM > To: 'Rémy Beaumont'; pgsql-performance@postgresql.org > Subject: Re: [PERFORM] High load and iowait but no disk access > >

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Anjan Dave
?   Thanks, Anjan From: Woody Woodring [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 2:30 PM To: 'Rémy Beaumont'; pgsql-performance@postgresql.org Subject: Re: [PERFORM] High load and iowait but no disk access   Have you tried a different kernel?  We run with a n

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Rémy Beaumont
nt'; pgsql-performance@postgresql.org Subject: Re: [PERFORM] High load and iowait but no disk access   Have you tried a different kernel?  We run with a netapp over NFS without any issues, but we have seen high IO-wait on other Dell boxes (running  and not running postgres) and RHES 3.  We

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Rémy Beaumont
On 30-Aug-05, at 14:32, Josh Berkus wrote: Remy, The behavior we see is that when running queries that do random reads on disk, IOWAIT goes over 80% and actual disk IO falls to a crawl at a throughput bellow 3000kB/s (We usually average 4 kB/s to 8 kB/s on sequential read operations

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Woody Woodring
ehalf Of Rémy BeaumontSent: Monday, August 29, 2005 9:43 AMTo: pgsql-performance@postgresql.orgSubject: [PERFORM] High load and iowait but no disk access We have been trying to pinpoint what originally seem to be a I/O bottleneck but which now seems to be an issue with either Postgresql or RHES

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Josh Berkus
Remy, > The behavior we see is that when running queries that do random reads > on disk, IOWAIT goes over 80% and actual disk IO falls to a crawl at a > throughput bellow 3000kB/s (We usually average 4 kB/s to 8 kB/s > on sequential read operations on the netapps) This seems pretty low fo

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Rémy Beaumont
On 30-Aug-05, at 12:29, Tom Lane wrote: =?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes: On 30-Aug-05, at 12:15, Tom Lane wrote: I know zip about NetApps, but doesn't the 8th column indicate pretty steady disk reads? Yes, but they are very low. Sure, but that's more or less w

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Tom Lane
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes: > On 30-Aug-05, at 12:15, Tom Lane wrote: >> I know zip about NetApps, but doesn't the 8th column indicate pretty >> steady disk reads? > Yes, but they are very low. Sure, but that's more or less what you'd expect if the thing is random

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Tom Lane
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes: > The stats of the NetApp do confirm that it is sitting idle. Really? > CPU NFS CIFS HTTP TotalNet kB/s Disk kB/s Tape kB/s > Cache Cache CP CP Disk DAFS FCP iSCSI FCP kB/s >

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Michael Stone
On Mon, Aug 29, 2005 at 09:42:46AM -0400, Rémy Beaumont wrote: We have been trying to pinpoint what originally seem to be a I/O bottleneck but which now seems to be an issue with either Postgresql or RHES 3. Nope, it's an IO bottleneck. The behavior we see is that when running queries that d

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread Rémy Beaumont
On 30-Aug-05, at 12:15, Tom Lane wrote: =?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes: The stats of the NetApp do confirm that it is sitting idle. Really? CPU NFS CIFS HTTP TotalNet kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk DAFS FCP iSCSI

[PERFORM] High load and iowait but no disk access

2005-08-30 Thread Rémy Beaumont
We have been trying to pinpoint what originally seem to be a I/O bottleneck but which now seems to be an issue with either Postgresql or RHES 3. We have the following test environment on which we can reproduce the problem: 1) Test System A Dell 6650 Quad Xeon Pentium 4 8 Gig of RAM OS: RHES 3 upd