Skip site navigation (1) Skip section navigation (2)

Re: Inserting 8MB bytea: just 25% of disk perf used?

From: Richard Huxton <dev(at)archonet(dot)com>
To: "fkater(at)googlemail(dot)com" <fkater(at)googlemail(dot)com>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Inserting 8MB bytea: just 25% of disk perf used?
Date: 2010-01-19 12:16:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 19/01/10 10:50, fkater(at)googlemail(dot)com wrote:
> However, the deeper question is (sounds ridiculous): Why am
> I I/O bound *this much* here. To recall: The write
> performance in pg is about 20-25% of the worst case serial
> write performance of the disk (and only about 8-10% of the
> best disk perf) even though pg_xlog (WAL) is moved to
> another disk, only 10 simple INSERT commands, a simple table
> of 5 columns (4 unused, one bytea) and one index for OID, no
> compression since STORAGE EXTERNAL, ntfs tweaks (noatime
> etc), ...

I'm no Windows expert, but the sysinternals tools (since bought by 
Microsoft) have always proved useful to me.

Diskmon should show you what's happening on your machine:

Be aware that this will generate a *lot* of data very quickly and you'll 
need to spend a little time analysing it. Try it without PG running to 
see what your system is up to when "idle" first to get a baseline.

Unfortunately it doesn't show disk seek times (which is probably what 
you want to measure) but it should let you decode what reads/writes are 
taking place when. If two consecutive disk accesses aren't adjacent then 
that implies a seek of course. Worst case you get two or more processes 
each accessing different parts of the disk in an interleaved arrangement.

   Richard Huxton
   Archonet Ltd

In response to

pgsql-performance by date

Next:From: Willy-Bas LoosDate: 2010-01-19 12:59:41
Subject: renice on an I/O bound box
Previous:From: Ivan VorasDate: 2010-01-19 11:52:24
Subject: Re: Inserting 8MB bytea: just 25% of disk perf used?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group