On 10/02/2016 12:23 AM, John Gorman wrote:
I reproduced the quadradic pfree performance problem and verified
that these patches solved it.
The slab.c data structures and functions contain no quadradic
components.
I noticed the sizing loop in SlabContextCreate() and came up with a
similar formula to determine chunksPerBlock that you arrived at.
;-)
Firstly, I've realized there's an issue when chunkSize gets too
large - once it exceeds blockSize, the SlabContextCreate() fails
as it's impossible to place a single chunk into the block. In
reorderbuffer, this may happen when the tuples (allocated in
tup_context) get larger than 8MB, as the context uses
SLAB_LARGE_BLOCK_SIZE (which is 8MB).
But maybe there's a simpler solution - we may simply cap the
chunkSize (in GenSlab) to ALLOC_CHUNK_LIMIT. That's fine, because
AllocSet handles those requests in a special way - for example
instead of tracking them in freelist, those chunks got freed
immediately.
I like this approach because it fixes the performance problems
with smaller allocations and doesn't change how larger
allocations are handled.
Right.
In slab.c it looks like a line in the top comments could be clearer.
Perhaps this is what is meant.
< * (plus alignment), now wasting memory.
* (plus alignment), not wasting memory.
In slab.c some lines are over 80 characters could be folded.
It would be nice to give each patch version a unique file name.
OK, will fix.
Nice patch, I enjoyed reading it!
;-)
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
