Thread: autoprewarm_dump_now

On 04/04/2025 16:40, Дарья Шанина wrote:
> Hello everyone!
> I have a question.
> 
> What would be better for the function autoprewarm_dump_now in case when 
> we need to allocate memory that exceeds 1 GB:

Hmm, so if I counted right, sizeof(BlockInfoRecord) == 20 bytes, which 
means that you can fit about 409 GB worth of buffers in a 1 GB 
allocation. So autoprewarm will currently not work with shared_buffers > 
409 GB. That's indeed quite unfortunate.

> 1) allocate enough memory for the entire shared_buffer array 
> (1..NBuffers) using palloc_extended;

That would be a pretty straightforward fix.

> 2) allocate the maximum of currently possible memory (1 GB) using an 
> ordinary palloc.

That'd put an upper limit on how much is prewarmed. It'd be a weird 
limitation. And prewarming matters the most with large shared_buffers.

3) Don't pre-allocate the array, write it out in a streaming fashion.

Unfortunately the file format doesn't make that easy: the number of 
entries is at the beginning of the file. You could count the entries 
beforehand, but the buffers can change concurrently. You could write a 
placeholder first, and seek back to the beginning of the file to fill in 
the real number at the end. The problem with that is that the number of 
bytes needed for the count itself varies. I suppose we could write some 
spaces as placeholders to accommodate the max count.

In apw_load_buffers(), we also load the file into (DSM) memory. There's 
no similar 1 GB limit in dsm_create(), but I think it's a bit 
unfortunate that the array needs to be allocated upfront upon loading.

In short, ISTM the easy answer here is "use palloc_extended". But 
there's a lot of room for further optimizations.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

On Fri, Apr 4, 2025 at 10:04 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> In apw_load_buffers(), we also load the file into (DSM) memory. There's
> no similar 1 GB limit in dsm_create(), but I think it's a bit
> unfortunate that the array needs to be allocated upfront upon loading.

Unrelated to this problem, but I wondered why autoprewarm doesn''t
launch background workers for each database simultaneously instead of
waiting for each one to finish a db before moving onto the next one.
Is it simply to limit the number of bgworkers taking up resources?

- Melanie

On Fri, Apr 4, 2025 at 12:17 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> Unrelated to this problem, but I wondered why autoprewarm doesn''t
> launch background workers for each database simultaneously instead of
> waiting for each one to finish a db before moving onto the next one.
> Is it simply to limit the number of bgworkers taking up resources?

That's probably part of it, but also (1) a system that allowed for
multiple workers would be somewhat more complex to implement and (2)
I'm not sure how beneficial it would be. We go to some trouble to make
the I/O as sequential as possible, and this would detract from that. I
also don't know how long prewarming normally takes -- if it's fast
enough already, then maybe this doesn't matter. But if somebody is
having a problem with autoprewarm being slow and wants to implement a
multi-worker system to make it faster, cool.

--
Robert Haas
EDB: http://www.enterprisedb.com