From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org> |
Subject: | Re: Make MemoryContextMemAllocated() more precise |
Date: | 2020-04-05 23:48:25 |
Message-ID: | 20200405234825.cz6mmmwlj3th53qp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2020-03-27 17:21:10 -0700, Jeff Davis wrote:
> Attached refactoring patch. There's enough in here that warrants
> discussion that I don't think this makes sense for v13 and I'm adding
> it to the July commitfest.
IDK, adding a commit to v13 that we know we should do architecturally
differently in v14, when the difference in complexity between the two
patches isn't actually *that* big...
I'd like to see others jump in here...
> I still think we should do something for v13, such as the originally-
> proposed patch[1]. It's not critical, but it simply reports a better
> number for memory consumption. Currently, the memory usage appears to
> jump, often right past work mem (by a reasonable but noticable amount),
> which could be confusing.
Is that really a significant issue for most work mem sizes? Shouldn't
the way we increase sizes lead to the max difference between the
measurements to be somewhat limited?
> * there's a new MemoryContextCount() that simply calculates the
> statistics without printing anything, and returns a struct
> - it supports flags to indicate which stats should be
> calculated, so that some callers can avoid walking through
> blocks/freelists
> * it adds a new statistic for "new space" (i.e. untouched)
> * it eliminates specialization of the memory context printing
> - the only specialization was for generation.c to output the
> number of chunks, which can be done easily enough for the
> other types, too
That sounds like a good direction.
> + if (flags & MCXT_STAT_NBLOCKS)
> + counters.nblocks = nblocks;
> + if (flags & MCXT_STAT_NCHUNKS)
> + counters.nchunks = set->nChunks;
> + if (flags & MCXT_STAT_FREECHUNKS)
> + counters.freechunks = freechunks;
> + if (flags & MCXT_STAT_TOTALSPACE)
> + counters.totalspace = set->memAllocated;
> + if (flags & MCXT_STAT_FREESPACE)
> + counters.freespace = freespace;
> + if (flags & MCXT_STAT_NEWSPACE)
> + counters.newspace = set->blocks->endptr - set->blocks->freeptr;
I'd spec it so that context implementations are allowed to
unconditionally fill fields, even when the flag isn't specified. The
branches quoted don't buy us anyting...
> diff --git a/src/include/nodes/memnodes.h b/src/include/nodes/memnodes.h
> index c9f2bbcb367..cc545852968 100644
> --- a/src/include/nodes/memnodes.h
> +++ b/src/include/nodes/memnodes.h
> @@ -29,11 +29,21 @@
> typedef struct MemoryContextCounters
> {
> Size nblocks; /* Total number of malloc blocks */
> + Size nchunks; /* Total number of chunks (used+free) */
> Size freechunks; /* Total number of free chunks */
> Size totalspace; /* Total bytes requested from malloc */
> Size freespace; /* The unused portion of totalspace */
> + Size newspace; /* Allocated but never held any chunks */
I'd add some reasoning as to why this is useful.
> } MemoryContextCounters;
>
> +#define MCXT_STAT_NBLOCKS (1 << 0)
> +#define MCXT_STAT_NCHUNKS (1 << 1)
> +#define MCXT_STAT_FREECHUNKS (1 << 2)
> +#define MCXT_STAT_TOTALSPACE (1 << 3)
> +#define MCXT_STAT_FREESPACE (1 << 4)
> +#define MCXT_STAT_NEWSPACE (1 << 5)
s/MCXT_STAT/MCXT_STAT_NEED/?
> +#define MCXT_STAT_ALL ((1 << 6) - 1)
Hm, why not go for ~0 or such?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-04-05 23:54:19 | Re: CLOBBER_CACHE_ALWAYS regression instability |
Previous Message | Andres Freund | 2020-04-05 22:49:16 | WAL page magic errors (and plenty others) got hard to debug. |