Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, tender wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Date: 2024-02-26 16:16:44
Message-ID: 202402261616.dlriae7b6emv@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-Feb-23, Dilip Kumar wrote:

> 1.
> + * If no process is already in the list, we're the leader; our first step
> + * is to "close out the group" by resetting the list pointer from
> + * ProcGlobal->clogGroupFirst (this lets other processes set up other
> + * groups later); then we lock the SLRU bank corresponding to our group's
> + * page, do the SLRU updates, release the SLRU bank lock, and wake up the
> + * sleeping processes.
>
> I think here we are saying that we "close out the group" before
> acquiring the SLRU lock but that's not true. We keep the group open
> until we gets the lock so that we can get maximum members in while we
> are anyway waiting for the lock.

Absolutely right. Reworded that.

> 2.
> static void
> TransactionIdSetCommitTs(TransactionId xid, TimestampTz ts,
> RepOriginId nodeid, int slotno)
> {
> - Assert(TransactionIdIsNormal(xid));
> + if (!TransactionIdIsNormal(xid))
> + return;
> +
> + entryno = TransactionIdToCTsEntry(xid);
>
> I do not understand why we need this change.

Ah yeah, I was bothered by the fact that if you pass Xid values earlier
than NormalXid to this function, we'd reply with some nonsensical values
instead of throwing an error. But you're right that it doesn't belong
in this patch, so I removed that.

Here's a version with these fixes, where I also added some text to the
pg_stat_slru documentation:

+ <para>
+ For each <literal>SLRU</literal> area that's part of the core server,
+ there is a configuration parameter that controls its size, with the suffix
+ <literal>_buffers</literal> appended. For historical
+ reasons, the names are not exact matches, but <literal>Xact</literal>
+ corresponds to <literal>transaction_buffers</literal> and the rest should
+ be obvious.
+ <!-- Should we edit pgstat_internal.h::slru_names so that the "name" matches
+ the GUC name?? -->
+ </para>

I think I would like to suggest renaming the GUCs to have the _slru_ bit
in the middle:

+# - SLRU Buffers (change requires restart) -
+
+#commit_timestamp_slru_buffers = 0 # memory for pg_commit_ts (0 = auto)
+#multixact_offsets_slru_buffers = 16 # memory for pg_multixact/offsets
+#multixact_members_slru_buffers = 32 # memory for pg_multixact/members
+#notify_slru_buffers = 16 # memory for pg_notify
+#serializable_slru_buffers = 32 # memory for pg_serial
+#subtransaction_slru_buffers = 0 # memory for pg_subtrans (0 = auto)
+#transaction_slru_buffers = 0 # memory for pg_xact (0 = auto)

and the pgstat_internal.h table:

static const char *const slru_names[] = {
"commit_timestamp",
"multixact_members",
"multixact_offsets",
"notify",
"serializable",
"subtransaction",
"transaction",
"other" /* has to be last */
};

This way they match perfectly.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"All rings of power are equal,
But some rings of power are more equal than others."
(George Orwell's The Lord of the Rings)

Attachment Content-Type Size
v20-0001-Make-SLRU-buffer-sizes-configurable.patch text/x-diff 120.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Danil Anisimow 2024-02-26 16:29:26 Re: Comments on Custom RMGRs
Previous Message Andy Fan 2024-02-26 16:08:33 Re: Shared detoast Datum proposal