You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2014/09/02 14:02:25 UTC
Pool freelist
Has anyone looked at simply disabling the apr_pools freelist
totally lately and seeing what the performance is?
Re: Pool freelist
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 04 September 2014 01:07:49, Branko Čibej wrote:
> On 03.09.2014 23:15, Stefan Fritsch wrote:
> > On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote:
> >> It's now ~6 years later and so wondering if just bypassing
> >> the pool freelist is now viable, at least as a compile-time
> >> (or allocator) option.
> >
> > I don't see any reason against a non-default compile-time option.
> > Then people could test it more easily and give feedback.
>
> I do. Distro packages will tend to pick one or the other option, and
> if applications have no control over the behaviour, they'll
> mysteriously behave differently on different platforms (or even
> different distros of the same OS).
Unfortunately without a compile time option, you won't get enough
testing. And any significant change in the allocator will cause a
problem in some workload.
> We had, and possibly still have, the same problem with using mmap
> for pool allocation; I've seen an application mysteriously fail on
> some Linux distro because it "ran out of file handles", but turned
> out to be hitting a hard limit of the number of mmapped blocks
> (i.e., pools) per process. Because the distro packager happened to
> turn mmap for pools on at compile time.
I could never reproduce that issue. AFAICT, it is/was a kernel bug in
some Linux versions.
And the mmap allocator behaves significantly better in general (at
least for httpd). Maybe it should be made the default, at least on
linux.
> I don't think it's a good idea to put potential heisenbugs into the
> code by design. :)
>
> -- Brane
Re: Pool freelist
Posted by Branko Čibej <br...@apache.org>.
On 03.09.2014 23:15, Stefan Fritsch wrote:
> On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote:
>> It's now ~6 years later and so wondering if just bypassing
>> the pool freelist is now viable, at least as a compile-time
>> (or allocator) option.
> I don't see any reason against a non-default compile-time option. Then
> people could test it more easily and give feedback.
I do. Distro packages will tend to pick one or the other option, and if
applications have no control over the behaviour, they'll mysteriously
behave differently on different platforms (or even different distros of
the same OS).
We had, and possibly still have, the same problem with using mmap for
pool allocation; I've seen an application mysteriously fail on some
Linux distro because it "ran out of file handles", but turned out to be
hitting a hard limit of the number of mmapped blocks (i.e., pools) per
process. Because the distro packager happened to turn mmap for pools on
at compile time.
I don't think it's a good idea to put potential heisenbugs into the code
by design. :)
-- Brane
Re: Pool freelist
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote:
> It's now ~6 years later and so wondering if just bypassing
> the pool freelist is now viable, at least as a compile-time
> (or allocator) option.
I don't see any reason against a non-default compile-time option. Then
people could test it more easily and give feedback.
Cheers,
Stefan
Re: Pool freelist
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 4, 2014, at 7:03 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 3 September 2014 23:37, Jim Jagielski <ji...@jagunet.com> wrote:
>> Yeah, that thread, and Greg's work w/ pocore, are kind of
>> the origins of this question. The thing is that awhile ago,
>> (I mean way awhile ago), I recall us trying to simply replace
>> pools w/ malloc/free (Paul was the main dude in this case)
>> and we got terrible performance...
> Simply replacing pools within malloc/free is not good idea IMO
That's not what is being proposed.
Re: Pool freelist
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 3 September 2014 23:37, Jim Jagielski <ji...@jagunet.com> wrote:
> Yeah, that thread, and Greg's work w/ pocore, are kind of
> the origins of this question. The thing is that awhile ago,
> (I mean way awhile ago), I recall us trying to simply replace
> pools w/ malloc/free (Paul was the main dude in this case)
> and we got terrible performance...
Simply replacing pools within malloc/free is not good idea IMO,
because nice thing about pools that it has very good performance for
small allocations because data allocated with minimum 8kb chunks. So
it benefits for typical code like this:
[[
some_t *s = apr_pcalloc(pool, sizeof(*s));
s->string1 = apr_pstrdup(pool, s);
s->something = arp_pcalloc(pool, 11)
]]
--
Ivan Zhakov
Re: Pool freelist
Posted by Greg Stein <gs...@gmail.com>.
As I recall, Paul tested using tcmalloc or some other allocator to replace
apr_palloc(). No bueno.
The short answer is that pool-based allocation is *wicked* fast, compared
to any other attempt/mechanism for allocating memory. I managed to improve
over apr by removing an if-test or two, but any other approach will be
comparatively/miserably slow.
Now, that said: it sounds like you're not asking about apr_palloc(), but
really about apr_pool_create(). I believe that would likely be just fine
for something like HTTPD. On a per-request basis, it doesn't really
allocate many pools. But Subversion tends to create a pool for any for-loop
that might allocate memory. *Thousands* get created/destroyed across some
Subversion operation. On the client, another microsecond isn't going to be
a big deal, but the server exhibits this behavior too.
Is your goal to remove the burdens, and simplify the codebase? Or .. ???
Cheers,
-g
On Wed, Sep 3, 2014 at 2:37 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Yeah, that thread, and Greg's work w/ pocore, are kind of
> the origins of this question. The thing is that awhile ago,
> (I mean way awhile ago), I recall us trying to simply replace
> pools w/ malloc/free (Paul was the main dude in this case)
> and we got terrible performance...
>
> It's now ~6 years later and so wondering if just bypassing
> the pool freelist is now viable, at least as a compile-time
> (or allocator) option.
>
> On Sep 3, 2014, at 3:11 PM, Ivan Zhakov <ch...@gmail.com> wrote:
>
> > On 2 September 2014 16:02, Jim Jagielski <ji...@jagunet.com> wrote:
> >> Has anyone looked at simply disabling the apr_pools freelist
> >> totally lately and seeing what the performance is?
> > This thread may be interesting:
> > http://svn.haxx.se/dev/archive-2008-10/0070.shtml
> >
> > We also tested disabling apr_pools free list in our Subversion
> > distribution for Windows and didn't noticed performance problems on
> > simple tests. We didn't performed proper benchmarks and decided to
> > keep standard APR pools, but with very low MaxMemFree value.
> >
> > --
> > Ivan Zhakov
> >
>
>
Re: Pool freelist
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yeah, that thread, and Greg's work w/ pocore, are kind of
the origins of this question. The thing is that awhile ago,
(I mean way awhile ago), I recall us trying to simply replace
pools w/ malloc/free (Paul was the main dude in this case)
and we got terrible performance...
It's now ~6 years later and so wondering if just bypassing
the pool freelist is now viable, at least as a compile-time
(or allocator) option.
On Sep 3, 2014, at 3:11 PM, Ivan Zhakov <ch...@gmail.com> wrote:
> On 2 September 2014 16:02, Jim Jagielski <ji...@jagunet.com> wrote:
>> Has anyone looked at simply disabling the apr_pools freelist
>> totally lately and seeing what the performance is?
> This thread may be interesting:
> http://svn.haxx.se/dev/archive-2008-10/0070.shtml
>
> We also tested disabling apr_pools free list in our Subversion
> distribution for Windows and didn't noticed performance problems on
> simple tests. We didn't performed proper benchmarks and decided to
> keep standard APR pools, but with very low MaxMemFree value.
>
> --
> Ivan Zhakov
>
Re: Pool freelist
Posted by Ivan Zhakov <ch...@gmail.com>.
On 2 September 2014 16:02, Jim Jagielski <ji...@jagunet.com> wrote:
> Has anyone looked at simply disabling the apr_pools freelist
> totally lately and seeing what the performance is?
This thread may be interesting:
http://svn.haxx.se/dev/archive-2008-10/0070.shtml
We also tested disabling apr_pools free list in our Subversion
distribution for Windows and didn't noticed performance problems on
simple tests. We didn't performed proper benchmarks and decided to
keep standard APR pools, but with very low MaxMemFree value.
--
Ivan Zhakov