Hi, recently our production Subversion servers blew up to allocate ~20 GB of memory per Apache worker process (normal usage would be ~2 GB at most). The culprit turned out to repeated requests like this:
svn log --stop-on-copy --xml --revision 10574:74748
https://server/repository_root
(Don't ask why someone would do that over and over again :)
The thing to note here is:
- we're asking for a lot of revisions (~65 k)
- there's a total of ~580 k changed paths in these revisions
When I tried this request with an otherwise idle Apache I obeserved the
following memory usage (as reported by the VIRT column in top):
290m idle worker process after start of Apache
1463m after completion of the above request
We're using "SVNPathAuthz short_circuit". If I change that to
"SVNPathAuthz on" and repeat the experiment I get
290m idle worker process after start of Apache
374m after completion of the above request
So short_circuit path authorization is to blame.
I think the explanation is:
If we don't do short_circuit, then (cf. mod_dav_svn/authz.c)
ap_sub_req_method_uri("GET", ...)
is called foreach changed path. This runs with a freshly created
request_rec rsub
where rsub->pool is a sub-pool of the main r->pool. When the sub
request returns,
rsub and rsub->pool are destroyed. The actual work is done in
svn_repos_authz_check_access which gets passed rsub->pool.
But for short_circuit authz, svn_repos_authz_check_access is called from
subreq_bypass using the main request r->pool (cf.
mod_authz_svn/mod_authz_svn.c).
I.e. the memory used by svn_repos_authz_check_access accumulates over
the whole log-report HTTP request.
To fix, use a sub-pool in subreq_bypass when calling
svn_repos_authz_check_access.
After applying the attached patch I get (using "SVNPathAuthz short_circuit"):
290m idle worker process after start of Apache
393m after completion of the above request
Cheers, Roderich
subreq_bypass.patch
Description: Binary data
