You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Fridtjof Busse <fb...@gmx.de> on 2012/03/05 09:30:59 UTC
Memory leak in mod_sav_svn?
Hi,
we're running a SVN repo (~6GB) on 1.7.3.
Checking out the entire repo in one "svn co" (both 1.6 and 1.7) session is almost impossible.
The httpd process starts consuming up to 4GB and then dies, killing the svn client process with:
svn: REPORT of '/svn/prod/!svn/vcc/default': Could not read chunk size: connection was closed by server
Even more interesting, apache does not log anything in its error log.
To me, this looks like a memory leak.
Is there any way to debug this further?
Please CC me, thanks.
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
Re: Memory leak in mod_sav_svn?
Posted by Fridtjof Busse <fb...@gmx.de>.
* Daniel Shahaf <d....@daniel.shahaf.name>:
> Presumably, tcpdump/wireshark of the response headers will be useful.
The problem was very subtle:
Apache delivered a P3P header (our own configuration). This broke the checkout.
Why only a certain file was affected (it worked when the file was not in the repo) or why it worked when the configuration was "SVNAllowBulkUpdates On", I do not know yet.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Memory leak in mod_sav_svn?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Presumably, tcpdump/wireshark of the response headers will be useful.
Daniel
(no time to dive deeply into this right now, sorry)
Fridtjof Busse wrote on Tue, Mar 06, 2012 at 12:44:06 +0100:
> Hi,
>
> answering my own post:
>
> * Fridtjof Busse <fb...@gmx.de>:
> >
> > The httpd process starts consuming up to 4GB and then dies, killing the
> > svn client process with:
> > svn: REPORT of '/svn/prod/!svn/vcc/default': Could not read chunk size:
> > connection was closed by server
>
> Setting the configuration to
> SVNAllowBulkUpdates Off
> seems to solve the memory consumption problem, but makes checking the repo out completly impossible.
> SVN dies like this:
>
> svn: GET of '/svn/prod/!svn/ver/4634/source/python26-PyYAML/trunk/PyYAML-3.10/ext/_yaml.c': Error reading response headers: Line too long
>
> Apache logs this:
>
> [Tue Mar 06 12:39:25 2012] [error] [client <snip>] Unable to deliver content. [500, #0]
> [Tue Mar 06 12:39:25 2012] [error] [client <snip>] (104)Connection reset by peer: Could not write data to filter. [500, #0]
> [Tue Mar 06 12:39:25 2012] [error] [client <snip>] Provider encountered an error while streaming a REPORT response. [500, #0]
> [Tue Mar 06 12:39:25 2012] [error] [client <snip>] A failure occurred while driving the update report editor [500, #103]
>
> Any ideas?
> Please CC me, thanks.
>
> --
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
Re: Memory leak in mod_sav_svn?
Posted by Fridtjof Busse <fb...@gmx.de>.
Hi,
answering my own post:
* Fridtjof Busse <fb...@gmx.de>:
>
> The httpd process starts consuming up to 4GB and then dies, killing the
> svn client process with:
> svn: REPORT of '/svn/prod/!svn/vcc/default': Could not read chunk size:
> connection was closed by server
Setting the configuration to
SVNAllowBulkUpdates Off
seems to solve the memory consumption problem, but makes checking the repo out completly impossible.
SVN dies like this:
svn: GET of '/svn/prod/!svn/ver/4634/source/python26-PyYAML/trunk/PyYAML-3.10/ext/_yaml.c': Error reading response headers: Line too long
Apache logs this:
[Tue Mar 06 12:39:25 2012] [error] [client <snip>] Unable to deliver content. [500, #0]
[Tue Mar 06 12:39:25 2012] [error] [client <snip>] (104)Connection reset by peer: Could not write data to filter. [500, #0]
[Tue Mar 06 12:39:25 2012] [error] [client <snip>] Provider encountered an error while streaming a REPORT response. [500, #0]
[Tue Mar 06 12:39:25 2012] [error] [client <snip>] A failure occurred while driving the update report editor [500, #103]
Any ideas?
Please CC me, thanks.
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
Re: Memory leak in mod_sav_svn?
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 05.03.2012 09:30, schrieb Fridtjof Busse:
> we're running a SVN repo (~6GB) on 1.7.3. Checking out the entire
> repo in one "svn co" (both 1.6 and 1.7) session is almost
> impossible. The httpd process starts consuming up to 4GB and then
> dies...
Note: The repository size and the size of a checkout are mostly
independent of each other. If you "svn remove" everything, your repo
will grow by a few bytes for the new revision. If you "svn copy" a file
to different locations inside the repository, it will only grow by a few
bytes for the new revision, but a checkout will contain multiple
independent copies of the files.
Anyhow, the question is what size the checkout really requires. The data
for this checkout is accumulated in memory and then sent to the client.
If this is more than the amount of memory you have, that's bad luck and
a natural limit, not a memory leak.
Another question is why you think you need the whole repository.
Depending on that, there might be different workarounds. What you can do
for sure is to check out with reduced depth and then update step by step
the missing child elements until you have a full repository. Other than
that, assuming a "normal" layout, you don't need the whole tags folder
for your work. In most cases you don't even need the branches folder,
only a few of them.
BTW: In order to pull the whole repository content including history,
svnsync is the tool of choice. However, that doesn't give you a working
copy but a mirror repository.
Good luck with whatever you are trying to achieve!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************