Re: Performance of COPY for Archive operations

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Performance of COPY for Archive operations
Date: 2004-09-16 00:30:32
Message-ID: 200409160030.i8G0UWh16363@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32


I can imagine WAL writing as fast as MS COPY, and I can imagine MS COPY
lagging behind on an I/O bound system. Remind me, how does the archvier
know a WAL file is full?

Suppose the system is 100% I/O bound. Archiver can just keep up with
WAL, but if WAL gets a lead, can archiver catch up? Basically archiver
can never get ahead of WAL but WAL can get ahead of archiver.
Statistically does that cause a consistent lag? I am not sure.

---------------------------------------------------------------------------

Simon Riggs wrote:
> > Bruce Momjian wrote
> > Simon Riggs wrote:
> > >
> > > I've spent a while working with PITR functionality on the Win32 port.
> > >
> > > I noticed that *it works*, which is always great, but using a
> > COPY command
> > > the archival operation was significantly slower than the writing of the
> > > xlogs themselves.
> > >
> > > At one point, I got to being more than 10 xlog files behind
> > with the list
> > > growing steadily, and took a while to clear the logjam when my test
> > > workloads completed. Not much point having archiving thats
> > actually slower
> > > than the writing of xlog....
> >
> > Why was it slow? 'cp' was slower than the WAL writes? Seems strange to
> > me. Do we have some sleep loop in there that is causing us to read
> > that directory too slowly? I didn't think so.
> >
>
> (Win32 COPY, not cp.)
>
> Yes, it seemed strange, that's why I mention it... nothing like that on
> linux.
>
> When there are multiple files ready for archive, ARCHIVER loops until
> they're all done. You're right, it could conceivably be something to do with
> directory access speed, but I'm thinking that the NT COPY command itself has
> some strangeness.
>
> My test involved writing 1 million records, each > 4k to a table using an
> Insert Select. The Server had a single disk, but there's no reason to expect
> that head movement on the disk would favour one process over another. That's
> probably THE most common setup for people using the Windows version anyway,
> so it is important.
>
> I note also Mark Wong's recent large scale benchmark that showed less than a
> 1% overhead from archiving.
>
> > > IIRC the COPY command isn't the best thing to use for bulk-copying on
> > > Windows, but I can't remember what is better. Anybody?
> >
> > COPY is the fastest way to get data in and out of PostgreSQL.
>
> Agreed....but I meant copying NT files around using the NT COPY command, not
> the PostgreSQL COPY command.
>
> I had some performance issues in '98 related to this - just hoping some
> Win32 wiz will educate me...
>
> ...
>
>
> More importantly, can anybody repeat this result? I performed this twice,
> with the same results each time.
>
> Thanks,
>
> Best Regards, Simon Riggs
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Arcadius A. 2004-09-16 08:25:10 Troubles with beta2-dev3 on Windows XP
Previous Message Simon Riggs 2004-09-15 20:16:29 Re: Performance of COPY for Archive operations