On Sunday 06 February 2011, Stefan Fritsch wrote:
> Therefore I propose to use mmap/mumap in the apr_allocator instead
> of malloc, either as a compile time option or whenever
> max_mem_free is set for the allocator. This would then completely
> separate the allocations from apr_allocator and normal malloc and
> reduce fragmentation. And it would make apr_allocator_max_free_set
> actually give memory back to the OS.
>
> This would be a relatively simple change (compared to replacing the
> whole allocator). Sounds ok?
I have made some measurements for this, doing some relatively complex
requests (a dir index of a dir with 10000 files) with apr 1.4.2/httpd
trunk/mpm_event under Linux/glibc:
reqs/s mem usage
after tests
malloc MaxMemFree unlimited 42 92M
malloc MaxMemFree 128 41 93M
malloc MaxMemFree 4 43 70M
mmap MaxMemFree unlimited 45 85M
mmap MaxMemFree 512 43 66M
mmap MaxMemFree 128 35 31M
mmap MaxMemFree 4 32 21M
The accuracy is not too high, I guess all the numbers are taken to be
+/- 1.
As you see, the the current allocator_alloc version which uses malloc
does not really allow to give back significant ammounts of RAM to the
OS, regardless of MaxMemFree. But with mmap, MaxMemFree has a
significant effect. And with the same ammount of RAM used, the mmap
version is not slower than the malloc version. Therefore with Linux
glibc, the mmap version seems superior in all respects.
I will commit this alternative allocator selectable with a configure
option. For now, it will need to be manually selected. Later, we can
think about changing the default for some platforms.
Cheers,
Stefan
