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. Cheers, Stefan
