apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: [PATCH] APR pool scalability and efficiency
Date Sun, 11 May 2014 08:28:26 GMT
Hi Stefan,

On Sunday 11 May 2014 04:23:38, Stefan Fuhrmann wrote:
> The first and more important one was getting an OOM
> error because we hit the mmap region count limit on
> Ubuntu (mmap seems to be enabled in the system libs
> at least since 12.04 LTS).

Using mmap has the advantage that free memory can be given back to the 
OS much more often, which is a big advantage for httpd, especially 
with mpm prefork. Therefore I enabled use of mmap in Debian/Ubuntu.

> Its root cause was a large data
> structure (many small allocations) being built up in a single
> pool. That times multiple threads / concurrent requests
> exceeded the ~0.5GB limit (~64k regions x 8kB).
> [apr-pool-growth.*]

interesting. From my experience, Linux seems to merge adjacent 
anonymous mappings. How does the process map look when it goes OOM?
Does subversion create lots of file-backed mappings that are 
interspersed with anon mappings? Or does the OOM happen when one 
thread unmaps its memory, causing a lot of fragmentation?

> In a related scenario, we would allocate a large buffer
> (e.g. 64kB) in a temporary pool, clear the pool and then
> create another pool that is small (few allocations) but
> relatively long-lived. The APR allocator would then tend
> to reuse the large node for the new pool - wasting quite
> a bit of memory. [apr-allocator-efficiency.*]

I have thought about this case, too. A different approach would be to 
split the large node, take what was requested for the current 
allocation and put the rest back into the free list as a smaller node. 
This works only with mmap/munmap and not with malloc/free, of course.
Not sure which method is better. One could do both, I guess.

> Attached are patches against apr/trunk to both issues plus
> the corresponding commit messages. Neither should change
> the behavior of "common" pool usage but rather improve
> "worst-case" behavior.


View raw message