Hi,
On Wed, 23 Feb 2005, Stephan Kulow wrote:
> Doing some strace on the server it became obvious, that the server was
> simply running out of memory. Having had some bad experience with cvs,
> we set a ulimit on our server to disallow (unintended) DoS attacks. But
> 128MB are fine to do a commit, no?
>
> Now before the server was aborted due the ulimit, it was acting like
> this in the strace:
>
> open("/home/kde/db/revs/330743", O_RDONLY|O_LARGEFILE) = 4
> _llseek(4, 8452, [8452], SEEK_SET) = 0
> read(4, "id: 1.0.r330743/8452\ntype: dir\np"..., 4096) = 627
> close(4) = 0
> [... opening _all_ revs in reverse, even those not containing files
> touched by the commit ...]
> Why is svnserve (version 1.1.3 btw) doing that? If this is happening
> whenever two people commit at the same time, then I'm afraid this would
> make KDE moving to subversion impossible ;(
It's 100% reproducable, so any idea anyone on this list? Anything we can
try to help solving this problem (short of using bdb, and does it really
not have this problem of opening all revs, even if it couldn't be
noticed by a simple strace)? This is a showstopper for using svn as
KDEs version management system, as concurrent commits to separate subtrees
need to be possible.
AFAIU the above shouldn't happen due to skip lists (or however you call
them ;-)) and anyway should touch only revs affected by the commit, not
all of them, but the strace shows that this is not the case.
Ciao,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 25 22:38:22 2005