1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Add pg_buffercache_numa view with NUMA node info

Introduces a new view pg_buffercache_numa, showing NUMA memory nodes
for individual buffers. For each buffer the view returns an entry for
each memory page, with the associated NUMA node.

The database blocks and OS memory pages may have different size - the
default block size is 8KB, while the memory page is 4K (on x86). But
other combinations are possible, depending on configure parameters,
platform, etc. This means buffers may overlap with multiple memory
pages, each associated with a different NUMA node.

To determine the NUMA node for a buffer, we first need to touch the
memory pages using pg_numa_touch_mem_if_required, otherwise we might get
status -2 (ENOENT = The page is not present), indicating the page is
either unmapped or unallocated.

The view may be relatively expensive, especially when accessed for the
first time in a backend, as it touches all memory pages to get reliable
information about the NUMA node. This may also force allocation of the
shared memory.

Author: Jakub Wartak <jakub.wartak@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Tomas Vondra <tomas@vondra.me>
Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com
This commit is contained in:
Tomas Vondra
2025-04-07 22:56:57 +02:00
parent 8cc139bec3
commit ba2a3c2302
10 changed files with 452 additions and 4 deletions

View File

@ -30,7 +30,9 @@
<para>
This module provides the <function>pg_buffercache_pages()</function>
function (wrapped in the <structname>pg_buffercache</structname> view),
the <function>pg_buffercache_summary()</function> function, the
<function>pg_buffercache_numa_pages()</function> function (wrapped in the
<structname>pg_buffercache_numa</structname> view), the
<function>pg_buffercache_summary()</function> function, the
<function>pg_buffercache_usage_counts()</function> function and
the <function>pg_buffercache_evict()</function> function.
</para>
@ -42,6 +44,15 @@
convenient use.
</para>
<para>
The <function>pg_buffercache_numa_pages()</function> provides
<acronym>NUMA</acronym> node mappings for shared buffer entries. This
information is not part of <function>pg_buffercache_pages()</function>
itself, as it is much slower to retrieve.
The <structname>pg_buffercache_numa</structname> view wraps the function for
convenient use.
</para>
<para>
The <function>pg_buffercache_summary()</function> function returns a single
row summarizing the state of the shared buffer cache.
@ -200,6 +211,78 @@
</para>
</sect2>
<sect2 id="pgbuffercache-pg-buffercache-numa">
<title>The <structname>pg_buffercache_numa</structname> View</title>
<para>
The definitions of the columns exposed by the view are shown in <xref linkend="pgbuffercache-numa-columns"/>.
</para>
<table id="pgbuffercache-numa-columns">
<title><structname>pg_buffercache_numa</structname> Columns</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>bufferid</structfield> <type>integer</type>
</para>
<para>
ID, in the range 1..<varname>shared_buffers</varname>
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>os_page_num</structfield> <type>int</type>
</para>
<para>
number of OS memory page for this buffer
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>numa_node</structfield> <type>int</type>
</para>
<para>
ID of <acronym>NUMA</acronym> node
</para></entry>
</row>
</tbody>
</tgroup>
</table>
<para>
As <acronym>NUMA</acronym> node ID inquiry for each page requires memory pages
to be paged-in, the first execution of this function can take a noticeable
amount of time. In all the cases (first execution or not), retrieving this
information is costly and querying the view at a high frequency is not recommended.
</para>
<warning>
<para>
When determining the <acronym>NUMA</acronym> node, the view touches
all memory pages for the shared memory segment. This will force
allocation of the shared memory, if it wasn't allocated already,
and the memory may get allocated in a single <acronym>NUMA</acronym>
node (depending on system configuration).
</para>
</warning>
</sect2>
<sect2 id="pgbuffercache-summary">
<title>The <function>pg_buffercache_summary()</function> Function</title>