Обсуждение: pg_dump performance issues

Dominique:

On Thu, 22 Feb 2024 at 10:50, Dominique Devienne <ddevienne@gmail.com> wrote:
> In the past, I've read [this post][1] from Marc Millas that reports `pg_dump ... | psql` at throughput around 500MB/s
(5Gb/s)on a 10Gb/s network.
 

That is half the theoretical bandwidth,more or less.

> I tried against a v12 and v14 Linux servers (real hardware, server-class machines, in the $10K range each, 2 years
oldand 7 years old, running RedHat 7)
 
> I'm on a 1Gb/s LAN.
The you would max out at about 50 if getting the same behaviour as
your reference.

> The client side is a Windows 11 PRO desktop running 16.1 release builds of pg_dump (and my own client).

Before doing any more thing you should test the network throughput
between your client and servers, on a naked connection. There are
plenty of programs for these, even a ftp/scp/network file copy would
be a useful reference. You have not provided any and.....

> .... in the 10-12MB/s throughput range.....

This has the faint smell of a saturated 100Mbps link in the middle (12*8=96Mbps)

Make some tests of the network and measure ( and post them ) before,
so people can guesstimate something.

Francisco Olarte.

On 2/22/24 06:40, Dominique Devienne wrote:
> On Thu, Feb 22, 2024 at 12:20 PM Dominique Devienne <ddevienne@gmail.com 
> <mailto:ddevienne@gmail.com>> wrote:
> 
>     On Thu, Feb 22, 2024 at 11:41 AM Francisco Olarte
>     <folarte@peoplecall.com <mailto:folarte@peoplecall.com>> wrote:
> 
>         Dominique:
>          > .... in the 10-12MB/s throughput range.....
> 
>         This has the faint smell of a saturated 100Mbps link in the
>         middle (12*8=96Mbps)
> 
> 
>     So indeed, I'm not on 1Gb/s as I expected... I'll report back when
>     this is fixed.
> 
> 
> So IT fixing the networking on my Windows machine is slower than I 
> expected...
> 
> Thus I switched to a Linux client, which I verified using iperf3 really 
> has 1Gbps.
> And there I can read at 100MB/s, which is almost saturating the network 
> link.
> The Linux dumps are 45MB this time, instead of 100MB on Windows, as if 
> the former is compressed, and the latter isn't.

Did you use the same pg_dump command on the Windows client?

Where was the Windows client Postgres software installed from?

Where was the Linux client Postgres software installed from?

> Perhaps the (implicit?) compression of the dump is why it's 8x slower 
> than mine? (I do fewer catalog queries I suspect)

 From

https://www.postgresql.org/docs/current/app-pgdump.html

d
directory

  <...>
  This format is compressed by default using gzip and also supports 
parallel dumps.

> And I see no speedup from parallelizing, unfortunately, which I find 
> strange, as mentioned earlier. Any idea why?

 From same link as above

-j njobs
--jobs=njobs

Run the dump in parallel by dumping njobs tables simultaneously. This 
option may reduce the time needed to perform the dump but it also 
increases the load on the database server. You can only use this option 
with the directory output format because this is the only output format 
where multiple processes can write their data at the same time.

<...>


I'm guessing on this small a database the overhead of -j is greater then 
the benefit derived.


> Note that this is against the v12 server, and the client is still 16.1.
> 
> Applying a two-threaded producer-consumer scheme to my dump, to 
> parallelize reads and writes, I might approach 100MB/s overall.
> Before getting into parallelizing reads, which complicate matters, and 
> my dump container's API is serial anyway (it's SQLite...)
> 
> So looks like I'm networking bound on 1Gbps, while Marc perhaps reached 
> PostgreSQL's (or the disks'?) limits before saturating his 10Gbps 
> networking.
> 
> Thanks, --DD
> 
> [ddevienne]$ my_dump ...
> COPY:         25x (   88,073 rows,     56,768,104 bytes) in   0.537s 
> (100.7 MB/s)
> DUMP'd 88,023 rows (56,761,583 bytes) from 25 tables in 1.062s (51.0 MB/s)
> 
> [ddevienne]$ ll ....db
> -rw-r--r-- 1 ddevienne users 58,351,616 Feb 22 15:10 ....db
> 
> [ddevienne]$ time $PDGM_POSTGRESQL_DIR/bin/pg_dump --role="..." -Fc -n 
> '"..."' -f ...-Fc.dump "host=acme dbname=copyperf"
> 7.561u 0.216s 0:08.46 91.8%     0+0k 0+91056io 0pf+0w
> [ddevienne]$ time $PDGM_POSTGRESQL_DIR/bin/pg_dump --role="..." -Fd -n 
> '"..."' -f ...-Fd.dump "host=acme dbname=copyperf"
> 7.351u 0.219s 0:08.33 90.7%     0+0k 0+90808io 0pf+0w
> [ddevienne]$ time $PDGM_POSTGRESQL_DIR/bin/pg_dump --role="..." -Fd -j2 
> -n '"..."' -f ...-Fdj2.dump "host=acme dbname=copyperf"
> 7.667u 0.228s 0:08.56 92.0%     0+0k 0+90808io 0pf+0w
> [ddevienne]$ time $PDGM_POSTGRESQL_DIR/bin/pg_dump --role="..." -Fd -j3 
> -n '"..."' -f ...-Fdj3.dump "host=acme dbname=copyperf"
> 7.964u 0.247s 0:08.71 94.1%     0+0k 0+90808io 0pf+0w
> [ddevienne]$ time $PDGM_POSTGRESQL_DIR/bin/pg_dump --role="..." -Fd -j4 
> -n '"..."' -f ...-Fdj4.dump "host=acme dbname=copyperf"
> 7.491u 0.243s 0:08.21 94.1%     0+0k 0+90808io 0pf+0w
> [ddevienne]$ du -sm ...-F*
> 45      ...-Fc.dump
> 45      ...-Fd.dump
> 45      ...-Fdj2.dump
> 45      ...-Fdj3.dump
> 45      ...-Fdj4.dump

-- 
Adrian Klaver
adrian.klaver@aklaver.com