Re: slab allocator performance issues - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: slab allocator performance issues
Date
Msg-id 6717ca90-a2ea-b17d-f544-37f5181b1175@enterprisedb.com
Whole thread Raw
In response to Re: slab allocator performance issues  (Andres Freund <andres@anarazel.de>)
Responses Re: slab allocator performance issues
List pgsql-hackers
Hi,

I spent a bit of time benchmarking this - the first patch adds an 
extension with three functions, each executing a slightly different 
allocation pattern:

1) FIFO (allocates and frees in the same order)
2) LIFO (frees in reverse order)
3) random

Each function can also do a custom number of iterations, each allocating 
and freeing certain number of chunks. The bench.sql script executes 
three combinations (for each pattern)

1) no loops
2) increase: 100 loops, each freeing 10k chunks and allocating 15k
3) decrease: 100 loops, each freeing 10k chunks and allocating 5k

The idea is to test simple one-time allocation, and workloads that mix 
allocations and frees (to see how the changes affect reuse etc.).

The script tests this with a range of block sizes (1k-32k) and chunk 
sizes (32B-512B).

In the attached .ods file with results, the "comparison" sheets are the 
interesting ones - the last couple columns compare the main metrics for 
the two patches (labeled patch-1 and patch-2) to master.

Overall, the results look quite good - patch-1 is mostly on par with 
master, with maybe 5% variability in both directions. That's expected, 
considering the patch does not aim to improve performance.

The second patch brings some nice improvements - 30%-50% in most cases 
(for both allocation and free) seems pretty nice. But for the "increase" 
FIFO pattern (incrementally allocating/freeing more memory) there's a 
significant regression - particularly for the allocation time. In some 
cases (larger chunks, block size does not matter too much) it jumps from 
25ms to almost 200ms.

This seems unfortunate - the allocation pattern (FIFO, allocating more 
memory over time) seems pretty common, and the slowdown is significant.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
Next
From: Gilles Darold
Date:
Subject: Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace