Re: Separate memory contexts for relcache and catcache - Mailing list pgsql-hackers
| From | Melih Mutlu |
|---|---|
| Subject | Re: Separate memory contexts for relcache and catcache |
| Date | |
| Msg-id | CAGPVpCTYd-sta5Js--2rh4Vr6gG_7ZzVtSEsKBe+GG+_JmKDRw@mail.gmail.com Whole thread Raw |
| In response to | Separate memory contexts for relcache and catcache (Melih Mutlu <m.melihmutlu@gmail.com>) |
| List | pgsql-hackers |
Hi Rahila,
Rahila Syed <rahilasyed90@gmail.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 ownand 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 bycreating a large number of new contexts in each backend, I would like to take a stepback and better understand the motivation behind separating these contexts.
IIUC, segregating cache memory allocations into RelCacheContext and CatCacheContextallows for grouping a large number of memory allocations under acommon 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 designedto 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.
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 growlarge 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 forSPICacheContext 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.
Thanks,
Melih Mutlu
Microsoft
pgsql-hackers by date: