Potential regression: high server-side memory consumption during import (was: Subversion 1.10 RC1?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential regression: high server-side memory consumption during import (was: Subversion 1.10 RC1?)

Evgeny Kotkov
Julian Foad <[hidden email]> writes:

> After any issues raised in this discussion are resolved, we feel we should
> go ahead and produce RC1 as soon as possible.

I think that I am seeing a 1.10 regression in terms of httpd's memory
usage during large imports.

In my environment, when I `svn import` an unpacked version of Boost
(https://www.boost.org/) that consists of around 60,000 files, I see that
the memory consumption by the server process rapidly grows up to 1.5 GB.
The environment is a Windows 8.1 x64 machine with httpd 2.4.29 configured
to use short-circuit authz and HTTPS.  Apparently, this behavior is specific
to 1.10, as I cannot reproduce it with 1.9 binaries.

 (I haven't investigated the issue any further at this time, and it might as
  well be reproducible in other configurations.)


Thanks,
Evgeny Kotkov
Reply | Threaded
Open this post in threaded view
|

Re: Potential regression: high server-side memory consumption during import (was: Subversion 1.10 RC1?)

Stefan Fuhrmann
On 05.12.2017 22:05, Evgeny Kotkov wrote:

> Julian Foad <[hidden email]> writes:
>
>> After any issues raised in this discussion are resolved, we feel we should
>> go ahead and produce RC1 as soon as possible.
>
> I think that I am seeing a 1.10 regression in terms of httpd's memory
> usage during large imports.
>
> In my environment, when I `svn import` an unpacked version of Boost
> (https://www.boost.org/) that consists of around 60,000 files, I see that
> the memory consumption by the server process rapidly grows up to 1.5 GB.
> The environment is a Windows 8.1 x64 machine with httpd 2.4.29 configured
> to use short-circuit authz and HTTPS.  Apparently, this behavior is specific
> to 1.10, as I cannot reproduce it with 1.9 binaries.
>
>   (I haven't investigated the issue any further at this time, and it might as
>    well be reproducible in other configurations.)

Would it be possible for you to bisect this to
find the offending revision?  My random guess
would be that in the context of mod_dav_svn, we
might use an unsuitable pool for authz caching.

-- Stefan^2.