pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedpgdump slowness
5+ messages / 3 participants
[nested] [flat]
* pgdump slowness
@ 2019-09-12 15:35 Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 15:51 ` Re: pgdump slowness nikhil raj <nikhilraj474@gmail.com>
2019-09-12 15:52 ` Re: pgdump slowness Ron <ronljohnsonjr@gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: Dhandapani Shanmugam @ 2019-09-12 15:35 UTC (permalink / raw)
To: pgsql-admin
Hi Guys,
We are having wired issue. pg_dump taking more time to backup 320 GB of
table,the table has bytea data type with TOAST table associated it. Please
let me know, if this is the expected behavior of pg_dump or do i need to
tune any of the parameters. I tried to run pg_dump with parallel -j option
, still no improvement and there is no lock on the table as well. any
inputs are welcome
-D
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgdump slowness
2019-09-12 15:35 pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
@ 2019-09-12 15:51 ` nikhil raj <nikhilraj474@gmail.com>
2019-09-12 15:54 ` Re: pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: nikhil raj @ 2019-09-12 15:51 UTC (permalink / raw)
To: Dhandapani Shanmugam <postgresql95@gmail.com>; +Cc: pgsql-admin
Hi Dhandapani,
That is the system configuration and version and how many parallel job
you are running in the command.
Please let know the details.
On Thu, 12 Sep 2019, 9:05 pm Dhandapani Shanmugam, <postgresql95@gmail.com>
wrote:
> Hi Guys,
>
> We are having wired issue. pg_dump taking more time to backup 320 GB of
> table,the table has bytea data type with TOAST table associated it. Please
> let me know, if this is the expected behavior of pg_dump or do i need to
> tune any of the parameters. I tried to run pg_dump with parallel -j option
> , still no improvement and there is no lock on the table as well. any
> inputs are welcome
>
> -D
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgdump slowness
2019-09-12 15:35 pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 15:51 ` Re: pgdump slowness nikhil raj <nikhilraj474@gmail.com>
@ 2019-09-12 15:54 ` Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 16:48 ` Re: pgdump slowness Ron <ronljohnsonjr@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Dhandapani Shanmugam @ 2019-09-12 15:54 UTC (permalink / raw)
To: nikhil raj <nikhilraj474@gmail.com>; +Cc: pgsql-admin
Hi Nikhil,
I don't see any resource issues on server. the cpu shows 90% idle and the
load of the server is very normal. I am using 6 parallel process.
-D
On Thu, Sep 12, 2019 at 9:22 PM nikhil raj <nikhilraj474@gmail.com> wrote:
> Hi Dhandapani,
>
> That is the system configuration and version and how many parallel job
> you are running in the command.
>
> Please let know the details.
>
> On Thu, 12 Sep 2019, 9:05 pm Dhandapani Shanmugam, <postgresql95@gmail.com>
> wrote:
>
>> Hi Guys,
>>
>> We are having wired issue. pg_dump taking more time to backup 320 GB of
>> table,the table has bytea data type with TOAST table associated it. Please
>> let me know, if this is the expected behavior of pg_dump or do i need to
>> tune any of the parameters. I tried to run pg_dump with parallel -j option
>> , still no improvement and there is no lock on the table as well. any
>> inputs are welcome
>>
>> -D
>>
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgdump slowness
2019-09-12 15:35 pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 15:51 ` Re: pgdump slowness nikhil raj <nikhilraj474@gmail.com>
2019-09-12 15:54 ` Re: pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
@ 2019-09-12 16:48 ` Ron <ronljohnsonjr@gmail.com>
0 siblings, 0 replies; 5+ messages in thread
From: Ron @ 2019-09-12 16:48 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
IO load? Slow disks, low channel bandwidth, etc?
Is this a VM on an over-subscribed host?
On 9/12/19 10:54 AM, Dhandapani Shanmugam wrote:
> Hi Nikhil,
>
> I don't see any resource issues on server. the cpu shows 90% idle and the
> load of the server is very normal. I am using 6 parallel process.
>
> -D
>
> On Thu, Sep 12, 2019 at 9:22 PM nikhil raj <nikhilraj474@gmail.com
> <mailto:nikhilraj474@gmail.com>> wrote:
>
> Hi Dhandapani,
>
> That is the system configuration and version and how many parallel
> job you are running in the command.
>
> Please let know the details.
>
> On Thu, 12 Sep 2019, 9:05 pm Dhandapani Shanmugam,
> <postgresql95@gmail.com <mailto:postgresql95@gmail.com>> wrote:
>
> Hi Guys,
>
> We are having wired issue. pg_dump taking more time to backup 320
> GB of table,the table has bytea data type with TOAST table
> associated it. Please let me know, if this is the expected
> behavior of pg_dump or do i need to tune any of the parameters. I
> tried to run pg_dump with parallel -j option , still no
> improvement and there is no lock on the table as well. any inputs
> are welcome
>
> -D
>
--
Angular momentum makes the world go 'round.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgdump slowness
2019-09-12 15:35 pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
@ 2019-09-12 15:52 ` Ron <ronljohnsonjr@gmail.com>
1 sibling, 0 replies; 5+ messages in thread
From: Ron @ 2019-09-12 15:52 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
On 9/12/19 10:35 AM, Dhandapani Shanmugam wrote:
> Hi Guys,
>
> We are having wired issue. pg_dump taking more time to backup 320 GB of
> table,the table has bytea data type with TOAST table associated it. Please
> let me know, if this is the expected behavior of pg_dump or do i need to
> tune any of the parameters. I tried to run pg_dump with parallel -j option
> , still no improvement and there is no lock on the table as well. any
> inputs are welcome
It took 16 hours to dump a 3TB v8.4 database that's full of bytea fields,
using the 9.6 pg_dump with 8 threads. This was from one DC to another
*across a 10GB WAN link*.
Note that I *disabled compression* because the bytea fields contained
non-compressible images. Thus, the dump size was 2.2x larger than the
actual database.
With compression enabled, the dump took a *lot* longer (though I didn't
record those numbers).
Ron
--
Angular momentum makes the world go 'round.
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2019-09-12 16:48 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-09-12 15:35 pgdump slowness Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 15:51 ` nikhil raj <nikhilraj474@gmail.com>
2019-09-12 15:54 ` Dhandapani Shanmugam <postgresql95@gmail.com>
2019-09-12 16:48 ` Ron <ronljohnsonjr@gmail.com>
2019-09-12 15:52 ` Ron <ronljohnsonjr@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox