Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, tender wang <tndrwang@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-26T16:16:44Z
Lists: pgsql-hackers
Attachments
- v20-0001-Make-SLRU-buffer-sizes-configurable.patch (text/x-diff)
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)
Commits
-
Fix zeroing of pg_serial page without SLRU bank lock
- be2f07310063 17.0 landed
-
Fix misspelled assertions
- 0d3a71d0c8a7 17.0 landed
-
GUC table: Add description to computed variables
- 30b8d6e4ce11 17.0 landed
-
Improve performance of subsystems on top of SLRU
- 53c2a97a9266 17.0 landed
-
Rename SLRU elements in view pg_stat_slru
- bcdfa5f2e2f2 17.0 landed
-
Use atomic access for SlruShared->latest_page_number
- d172b717c6f4 17.0 landed
-
Split use of SerialSLRULock, creating SerialControlLock
- 7b745d85b80d 17.0 landed
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 cited
-
Add a macro templatized hashtable.
- b30d3ea824c5 10.0 cited