Re: reducing memory usage by using "proxy" memory contexts?

On Mon, Dec 16, 2019 at 03:35:12PM -0800, Andres Freund wrote:
>Hi,
>
>I was responding to a question about postgres' per-backend memory usage,
>making me look at the various contexts below CacheMemoryContext. There
>is pretty much always a significant number of contexts below, one for
>each index:
>
> CacheMemoryContext: 524288 total in 7 blocks; 8680 free (0 chunks); 515608 used
> index info: 2048 total in 2 blocks; 568 free (1 chunks); 1480 used: pg_class_tblspc_relfilenode_index
> index info: 2048 total in 2 blocks; 960 free (0 chunks); 1088 used: pg_statistic_ext_relid_index
> index info: 2048 total in 2 blocks; 976 free (0 chunks); 1072 used: blarg_pkey
> index info: 2048 total in 2 blocks; 872 free (0 chunks); 1176 used: pg_index_indrelid_index
> index info: 2048 total in 2 blocks; 600 free (1 chunks); 1448 used: pg_attrdef_adrelid_adnum_index
> index info: 2048 total in 2 blocks; 656 free (2 chunks); 1392 used: pg_db_role_setting_databaseid_rol_index
> index info: 2048 total in 2 blocks; 544 free (2 chunks); 1504 used: pg_opclass_am_name_nsp_index
> index info: 2048 total in 2 blocks; 928 free (2 chunks); 1120 used: pg_foreign_data_wrapper_name_index
> index info: 2048 total in 2 blocks; 960 free (2 chunks); 1088 used: pg_enum_oid_index
> index info: 2048 total in 2 blocks; 600 free (1 chunks); 1448 used: pg_class_relname_nsp_index
> index info: 2048 total in 2 blocks; 960 free (2 chunks); 1088 used: pg_foreign_server_oid_index
> index info: 2048 total in 2 blocks; 960 free (2 chunks); 1088 used: pg_publication_pubname_index
>...
> index info: 3072 total in 2 blocks; 1144 free (2 chunks); 1928 used: pg_conversion_default_index
>...
>
>while I also think we could pretty easily reduce the amount of memory
>used for each index, I want to focus on something else here:
>
>We waste a lot of space due to all these small contexts. Even leaving
>aside the overhead of the context and its blocks - not insignificant -
>they are mostly between ~1/2 a ~1/4 empty.
>
>At the same time we probably don't want to inline all of them into
>CacheMemoryContext - too likely to introduce bugs, and too hard to
>maintain leak free.
>
>
>But what if we had a new type of memory context that did not itself
>manage memory underlying allocations, but instead did so via the parent?
>If such a context tracked all the live allocations in some form of list,
>it could then free them from the parent at reset time. In other words,
>it'd proxy all memory management via the parent, only adding a separate
>name, and tracking of all live chunks.
>
>Obviously such a context would be less efficient to reset than a plain
>aset.c one - but I don't think that'd matter much for these types of
>use-cases. The big advantage in this case would be that we wouldn't
>have separate two separate "blocks" for each index cache entry, but
>instead allocations could all be done within CacheMemoryContext.
>
>Does that sound like a sensible idea?
>

I do think it's an interesting idea, worth exploring.

I agree it's probably OK if the proxy contexts are a bit less efficient,
but I think we can restrict their use to places where that's not an
issue (i.e. low frequency of resets, small number of allocated chunks
etc.). And if needed we can probably find ways to improve the efficiency
e.g. by replacing the linked list with a small hash table or something
(to speed-up pfree etc.). Or something.

I think the big question is what this would mean for the parent context.
Because suddenly it's a mix of chunks with different life spans, which
would originally be segregared in different malloc-ed blocks. And now
that would not be true, so e.g. after deleting the child context the
memory would not be freed but just moved to the freelist.

It would also confuse MemoryContextStats, which would suddenly not
realize some of the chunks are actually "owned" by the child context.
Maybe this could be improved, but only partially (unless we'd want to
have a per-chunk flag if it's owned by the context or by a proxy).

Not sure if this would impact accounting (e.g. what if someone creates a
custom aggregate, creating a separate proxy context per group?). Would
that work or not?

Also, would this need to support nested proxy contexts? That might
complicate things quite a bit, I'm afraid.

FWIW I don't know answers to these questions.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services