From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Andras Fabian <Fabian(at)atrada(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG_DUMP very slow because of STDOUT ?? |
Date: | 2010-07-13 01:43:20 |
Message-ID: | AANLkTinWYGQqwKzBKE6F6Uf3IrBl3IBvWVPJKmDawDEr@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jul 12, 2010 at 7:03 AM, Andras Fabian <Fabian(at)atrada(dot)net> wrote:
> This STDOU issue gets even weirder. Now I have set up our two new servers (identical hw/sw) as I would have needed to do so anyways. After having PG running, I also set up the same test scenario as I have it on our problematic servers, and started the COPY-to-STDOUT experiment. And you know what? Both new servers are performing well. No hanging, and the 3 GByte test dump was written in around 3 minutes (as expected). To make things even more complicated ... I went back to our production servers. Now, the first one - which I froze up with oprofile this morning and needed a REBOOT - is performing well too! It needed 3 minutes for the test case ... WTF? BUT, the second production server, which did not have a reboot, is still behaving badly.
I'm gonna take a scientific wild-assed guess that your machine was
rebuilding RAID arrays when you started out, and you had massive IO
contention underneath the OS level resulting in such a slow down.
Note that you mentioned ~5% IO Wait. That's actually fairly high if
you've got 8 to 16 cores or something like that. It's much better to
use iostat -xd 60 or something like that and look for IO Utilization
at the end of the lines.
Again, just a guess.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-07-13 02:13:01 | Re: PostgreSQL 9.0 beta 3 release announcement |
Previous Message | Andrew Bartley | 2010-07-13 00:09:48 | Re: Redundant database objects. |