diff options
author | Tomas Vondra <tomas.vondra@postgresql.org> | 2025-04-07 22:56:57 +0200 |
---|---|---|
committer | Tomas Vondra <tomas.vondra@postgresql.org> | 2025-04-07 23:08:17 +0200 |
commit | ba2a3c2302f1248496322eba917b17a421499388 (patch) | |
tree | 54101e42df554d6c4f04c0bb79263fb3b55efde7 /doc/src | |
parent | 8cc139bec34a2971b0682a04eb52ce7b3f5bb425 (diff) | |
download | postgresql-ba2a3c2302f1248496322eba917b17a421499388.tar.gz postgresql-ba2a3c2302f1248496322eba917b17a421499388.zip |
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
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/pgbuffercache.sgml | 85 |
1 files changed, 84 insertions, 1 deletions
diff --git a/doc/src/sgml/pgbuffercache.sgml b/doc/src/sgml/pgbuffercache.sgml index 802a5112d77..b5050cd7343 100644 --- a/doc/src/sgml/pgbuffercache.sgml +++ b/doc/src/sgml/pgbuffercache.sgml @@ -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> @@ -43,6 +45,15 @@ </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. </para> @@ -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> |