apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: reducing memory fragmentation
Date Wed, 16 Feb 2011 22:29:30 GMT
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.


View raw message