Re: SlabCheck leaks memory into TopMemoryContext
От | Andres Freund |
---|---|
Тема | Re: SlabCheck leaks memory into TopMemoryContext |
Дата | |
Msg-id | 20200116061732.vvpyexenaortpu5y@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: SlabCheck leaks memory into TopMemoryContext (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SlabCheck leaks memory into TopMemoryContext
|
Список | pgsql-hackers |
Hi, On 2020-01-16 00:09:53 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I just noticed that having a slab context around in an assertion build > > leads to performance degrading and memory usage going up. A bit of > > poking revealed that SlabCheck() doesn't free the freechunks it > > allocates. > > > It's on its own obviously trivial to fix. > > It seems like having a context check function do new allocations > is something to be avoided in the first place. Yea, that's why I was wondering about doing the allocation during context creation, for the largest size necessary of any context: /* bitmap of free chunks on a block */ freechunks = palloc(slab->chunksPerBlock * sizeof(bool)); or at the very least using malloc(), rather than another context. > It's basically assuming that the memory management mechanism is sane, > which makes the whole thing fundamentally circular, even if it's > relying on some other context to be sane. Is there a way to do the > checking without extra allocations? Probably not easily. Was wondering if the bitmap could be made more dense, and allocated on the stack. It could actually using one bit for each tracked chunk, instead of one byte. Would have to put in a clear lower limit of the allowed chunk size, in relation to the block size, however, to stay in a reasonable range. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: