Re: PostgreSQL performance on FreeBSD

From: David Chisnall <theraven_at_FreeBSD.org>
Date: Wed, 13 Aug 2014 10:58:42 +0100
On 12 Aug 2014, at 19:09, John Baldwin <jhb_at_FreeBSD.org> wrote:

> OTOH, I have actually seen junk profiling _improve_ performance in certain 
> cases as it forces promotion of allocated pages to superpages since all pages 
> are dirtied.  (I have a local hack that adds a new malloc option to explicitly 
> memset() new pages allocated via mmap() that gives the same benefit without 
> the junking overheadon each malloc() / free(), but it does increase physical 
> RAM usage.)

Do you get the same effect by adding MAP_ALIGNED_SUPER | MAP_PREFAULT_READ to the mmap() call in jemalloc?  I've been meaning to try the latter on BERI, as we spend a lot of time bouncing back and forth between user code and the TLB miss handlers.  Given that jemalloc asks for memory in 8MB chunks (I think via a single mmap call, although I'm not 100% certain), MAP_ALIGNED_SUPER should have little impact on any platform.  MAP_PREFAULT_READ may cause problems on machines with limited RAM and no swap (I don't know if the VM subsystem knows that it can safely discard a zero'd page that has been read but not written - I'd hope so, but it's been a while since I read that code).

It might be that we can make jemalloc autotune whether to use MAP_PREFAULT_READ depending on some heuristic.  I wonder if something as simple as 'turn it on after the first mmap call' would be enough: programs that don't use more than 8MB of RAM won't prefault, but after that the wasted physical memory becomes an increasingly small percentage.

David
Received on Wed Aug 13 2014 - 07:59:00 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC