Re: pgsql: Introduce pg_shmem_allocations_numa view

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Christoph Berg <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Date: Mon, 23 Jun 2025 23:14:28 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
	<[email protected]>
	<[email protected]>
	<kl4zd72eeaex7zcicpuvpsuslrs5nfvmab7xzt4jnvcjvd6mxw@tcp64c55qkpj>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>



On 6/23/25 22:51, Christoph Berg wrote:
> Re: Tomas Vondra
>> Didn't you say the first ~35 addresses succeed, right? What about the
>> addresses after that?
> 
> That was pg_shmem_allocations_numa. The pg_numa_query_pages() in there
> works (does not return -1), but then some of the status[] values are
> -14.
> 
> When pg_buffercache_numa fails, pg_numa_query_pages() itself
> returns -14.
> 
> The printed os_page_ptrs[] contents are the same for the failing and
> non-failing calls, so the problem is probably elsewhere.
> 
>         /* Fill pointers for all the memory pages. */
>         idx = 0;
>         for (char *ptr = startptr; ptr < endptr; ptr += os_page_size)
>         {
> +           if (idx < 50)
> +               elog(DEBUG1, "os_page_ptrs idx %d = %p", idx, ptr);
>             os_page_ptrs[idx++] = ptr;
> 
> 
> 20:47 myon@postgres =# select * from pg_buffercache_numa;
> DEBUG:  00000: os_page_ptrs idx 0 = 0xebc44000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 1 = 0xebc45000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 2 = 0xebc46000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 3 = 0xebc47000
...
> DEBUG:  00000: os_page_ptrs idx 47 = 0xebc73000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 48 = 0xebc74000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 49 = 0xebc75000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: NUMA: NBuffers=16384 os_page_count=32768 os_page_size=4096
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:385
> 2025-06-23 20:47:41.827 UTC [1368080] ERROR:  failed NUMA pages inquiry: Bad address
> 2025-06-23 20:47:41.827 UTC [1368080] STATEMENT:  select * from pg_buffercache_numa;
> ERROR:  XX000: failed NUMA pages inquiry: Bad address
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:396
> Time: 92.757 ms
> 
> 20:47 myon@postgres =# select * from pg_buffercache_numa;
> DEBUG:  00000: os_page_ptrs idx 0 = 0xebc44000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 1 = 0xebc45000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 2 = 0xebc46000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 3 = 0xebc47000
...> DEBUG:  00000: os_page_ptrs idx 46 = 0xebc72000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 47 = 0xebc73000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 48 = 0xebc74000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: os_page_ptrs idx 49 = 0xebc75000
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:375
> DEBUG:  00000: NUMA: NBuffers=16384 os_page_count=32768 os_page_size=4096
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:385
> DEBUG:  00000: NUMA: page-faulting the buffercache for proper NUMA readouts
> LOCATION:  pg_buffercache_numa_pages, pg_buffercache_pages.c:444
> Time: 24.547 ms
> 20:47 myon@postgres =#
> 

True. If it fails on first call, but succeeds on the other, then the
problem is likely somewhere else. But also on the second call we won't
do the memory touching. Can you try setting firstNumaTouch=false, so
that we do this on every call?


At the beginning you mentioned this is happening on i386, armel and
armhf - are all those in qemu? I've tried on my rpi5 (with 32-bit user
space), and there everything seems to work fine. But that's aarch64
kernel, just the user space if 32-bit.


regards

-- 
Tomas Vondra

view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox