Re: Separate memory contexts for relcache and catcache

Hi Rahila,

Rahila Syed <rahilasyed90(at)gmail(dot)com>, 26 Kas 2024 Sal, 13:40 tarihinde şunu
yazdı:

> Observations:
> 1. While there are a number of child contexts like index info of
> RelCacheContext,
> CatCacheContext does not have any children.
> 2. While there is a bunch of used memory in RelCacheContext and
> CatCacheContext,
> SPICacheContext and PlanCacheContext do not have any allocations of their
> own
> and serve only as parents for SPI and CachedPlan related contexts
> respectively.
>

Thanks for sharing your observations and the diagram.

> Having reviewed the discussion regarding potential fragmentation issues
> caused by
> creating a large number of new contexts in each backend, I would like to
> take a step
> back and better understand the motivation behind separating these contexts.
>
> IIUC, segregating cache memory allocations into RelCacheContext and
> CatCacheContext
> allows for grouping a large number of memory allocations under a
> common context, which, in turn, aids in monitoring memory consumption.
> However,
> I believe this reasoning does not apply to SPICacheContext and
> PlanCacheContext,
> as these contexts do not have any allocations of their own.
>
> How, then, does separating these contexts from CacheMemoryContext improve
> monitoring?
> Additionally, IIUC, these contexts are created as long-lived contexts, so
> they are not designed
> to optimize deletion of all their children via MemoryContextDelete on the
> parent.
>

I think it all depends on the level of granularity we want in grouping
cache-related memory contexts. Currently, we have relatively low
granularity, and increasing it comes with additional memory usage due to
the newly introduced memory contexts. Ideally, having separate contexts for
each cache type would allow us to see how much memory is allocated for
each, as Ashutosh mentioned [1]. Even if a context does not have any
allocations of its own, its children might still use some memory. I
understand that we can already see total memory usage in, e.g.,
PlanCacheContext, since all of its children are named CachedPlan* and we
can query based on this naming. However, this may not always hold true or
could change in the future (though I’m not sure how likely that is).

That said, these changes come with a cost, and it may not be worth it to
separate every single cache into its own context. IIUC, introducing
contexts for heavily used caches results in much less fragmentation. If
that’s the case, then I believe we should focus on RelCache and CatCache,
as they are heavily used since the backend starts. I see that you and
Ashutosh [2] mentioned that PlanCacheContext is less likely to be heavily
used, so we could consider leaving that context out for now.

>> Attached a separate patch to change initial sizes for relcache and
>> catcache contexts as they grow
>>
>
>
>> large from the start. This was suggested in the thread previously [1].
>> Also changed CacheMemoryContext to use ALLOCSET_START_SMALL_SIZES, so it
>> starts from 1KB.
>>
>
> Applying the same change to use ALLOCSET_START_SMALL_SIZES would be
> beneficial for
> SPICacheContext and PlanCacheContext contexts as well.
>

We can even use "ALLOCSET_SMALL_SIZES" if a context rarely has its own
allocations, or some non-default sizes. I'm also okay to not introduce
those new contexts at all, if that'd be what everyone agrees on.

[1]
https://www.postgresql.org/message-id/CAExHW5vLRUk%2B9ZxF4FgaqdfmU2e8JbWES7ijhA0Bd6_bekr%3DKw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAExHW5skNdLG-kDiKe5k0EHUjc9xumjogHOWtEJKgS_xMB2Vcg%40mail.gmail.com

Thanks,
--
Melih Mutlu
Microsoft