[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkin needs giga bytes of memory

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2004-09-04 12:25:46 CEST

On Sep 3, 2004, at 21:29, Ben Collins-Sussman wrote:

> On Fri, 2004-09-03 at 14:54, Barry Scott wrote:
>> I've just tried to checking 12,000 files that only had svn:eol-style
>> native set on them and it failed after
>> 1.2GB of VM was not enough. (1.0.6 windows client checkin to 1.1.0-rc2
>> FreeBSD HTTP server).
> We should have no memory leaks like this. Everything should be
> streamy,
> and memery use should stay small and roughly constant-sized.
> Can you please be more specific so we can reproduce and debug?

> - Was the 1.2GB VM on the client or the server

Problem on the Windows Client. The server did not have any noticeable
resource use (very nice).

> - How do we reproduce? Just create 12000 files with that property
> on
> them, 'svn add' and 'svn commit'? How big should the files be? How
> are they distributed around the tree?

1. Created a new repo and add a trunk dir to it.
2. svn Checkout trunk
3. svn add 11093 files total 260MB and are a mix of mostly text and
some binary,
in 1300 directories.
4. svn ci - no problem that I remember
5. Noticed that auto-props have been ingored (have not confirmed this
problem yet)
6. issue 11000 svn ps svn:eol-style native commands
7. svn ci ... windows reports its low on VM, task manger shows 1.2GB of
VM on the SVN process
before it fails.

Given that the about took many hours to run you will forgive me not
repeating the sequence.

As for debugging this, personally I'd using dmalloc from dmalloc.com.
valgrind slows things
down to much.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 4 12:26:46 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.