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

Memory problems with huge revs of a single file in FSFS

From: <george.stein_at_go4more.de>
Date: 2007-05-22 16:31:05 CEST


We found a problem when committing a huge revision (2**18+1 = 262145)
of one single file to a repository.

Client: Windows XP Prof SP2
Server: Windows Server 2003 SP1, total physical memory: 4 GB

Clients: svn, tortoisesvn
Version: 1.3.2, 1.4.2, 1.4.3
Fs-type: FSFS
Format: 3 (pre-1.4), 5 (1.4)
Protocol: file://, https://

The test case is a loop with echoing the revision number to a file
and then committing it, e.g. in a Windows command line:
> for /l %i in (1,1,262145) do (echo %i >f && svn ci -m"%i" f)

We observed that the commit of the first revision after 2 to the power
of n lasts longer than the other ones:
revision duration [sec]
2**12+1 2
2**13+1 14
2**14+1 36
2**15+1 84
2**16+1 190
2**17+1 316
2**18+1 commit aborted

For the last commit (2**18+1) we got the following error messages:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

svn: Commit failed (details follow):
svn: OPTIONS request failed on '/<location>/<repo>'
svn: OPTIONS of '/<location>/<repo>': SSL negotiation failed: Secure connection truncated (https://<server>)

We assume that it is a memory issue in FSFS: During the commit the
process permanently increases the memory until no memory is left and the
process aborts. Servers with less memory (1 GB) shows this behavior for
lower revisions, e.g. 2**17+1 (131073). The problem doesn't occur on BDB.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 22 16:31:32 2007

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

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