From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@lists.postgresql.org
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tv@fuzzy.cz>,
 PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: Use generation context to speed up tuplesorts
Date: Wed, 08 Dec 2021 16:51:17 +0100
Message-ID: <8046109.NyiUUSuA9g@aivenronan>
Organization: aiven
In-Reply-To: <bcdd4e3e-c12d-cd2b-7ead-a91ad416100a@enterprisedb.com>
References: 
 <CAApHDvoH4ASzsAOyHcxkuY01Qf++8JJ0paw+03dk+W25tQEcNQ@mail.gmail.com>
 <36829a8a-63d0-c428-89d5-07e49561973e@enterprisedb.com>
 <bcdd4e3e-c12d-cd2b-7ead-a91ad416100a@enterprisedb.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: 
 <https://www.postgresql.org/message-id/8046109.NyiUUSuA9g%40aivenronan>
Precedence: bulk

Le jeudi 9 septembre 2021, 15:37:59 CET Tomas Vondra a =E9crit :
> And now comes the funny part - if I run it in the same backend as the
> "full" benchmark, I get roughly the same results:
>=20
>       block_size | chunk_size | mem_allocated | alloc_ms | free_ms
>      ------------+------------+---------------+----------+---------
>            32768 |        512 |     806256640 |    37159 |   76669
>=20
> but if I reconnect and run it in the new backend, I get this:
>=20
>       block_size | chunk_size | mem_allocated | alloc_ms | free_ms
>      ------------+------------+---------------+----------+---------
>            32768 |        512 |     806158336 |   233909 |  100785
>      (1 row)
>=20
> It does not matter if I wait a bit before running the query, if I run it
> repeatedly, etc. The machine is not doing anything else, the CPU is set
> to use "performance" governor, etc.

I've reproduced the behaviour you mention.
I also noticed asm_exc_page_fault showing up in the perf report in that cas=
e.

Running an strace on it shows that in one case, we have a lot of brk calls,=
=20
while when we run in the same process as the previous tests, we don't.

My suspicion is that the previous workload makes glibc malloc change it's=20
trim_threshold and possibly other dynamic options, which leads to constantl=
y=20
moving the brk pointer in one case and not the other.

Running your fifo test with absurd malloc options shows that indeed that mi=
ght=20
be the case (I needed to change several, because changing one disable the=20
dynamic adjustment for every single one of them, and malloc would fall back=
 to=20
using mmap and freeing it on each iteration):

mallopt(M_TOP_PAD, 1024 * 1024 * 1024);
mallopt(M_TRIM_THRESHOLD, 256 * 1024 * 1024);
mallopt(M_MMAP_THRESHOLD, 4*1024*1024*sizeof(long));

I get the following results for your self contained test. I ran the query=20
twice, in each case, seeing the importance of the first allocation and the=
=20
subsequent ones:

With default malloc options:

 block_size | chunk_size | mem_allocated | alloc_ms | free_ms=20
=2D-----------+------------+---------------+----------+---------
      32768 |        512 |     795836416 |   300156 |  207557

 block_size | chunk_size | mem_allocated | alloc_ms | free_ms=20
=2D-----------+------------+---------------+----------+---------
      32768 |        512 |     795836416 |   211942 |   77207


With the oversized values above:

 block_size | chunk_size | mem_allocated | alloc_ms | free_ms=20
=2D-----------+------------+---------------+----------+---------
      32768 |        512 |     795836416 |   219000 |   36223


 block_size | chunk_size | mem_allocated | alloc_ms | free_ms=20
=2D-----------+------------+---------------+----------+---------
      32768 |        512 |     795836416 |    75761 |   78082
(1 row)

I can't tell how representative your benchmark extension would be of real l=
ife=20
allocation / free patterns, but there is probably something we can improve=
=20
here.

I'll try to see if I can understand more precisely what is happening.

=2D-=20
Ronan Dunklau