Hi all out there!
Maybe this can cast some light onto my repos corruption problem.
To me it looks that without obvious reason at times SVN (or
Berkeley) requests all memory in the world (and in space, too) and
fail:
Since the repository became notoriously corrupted here (W2K Pro
SP1, SVN .30, TSVN .19) I withdrew it from production and only
kept a "private" repos with two working copies fed with changes
from different "real" work stations. It contains text files only, all
binary files (mostly JPG & GIF) were dumpfiltered. Both the
working copies and the repos are on my local machine, the repos
is accessed via Apache/http.
This worked without any trouble for several days for about 35
update/commit cycles, some large (up to 700 files in one commit),
some normal (50-100 files), some minor (less than 10 files). The
repos that had become practically unusable in production thereby
raised from rev. 61 (last in production) to rev. 97. Rev. 97
successfully committed about 40 files.
The attempt to update the other working copy to rev. 97 with these
40 files resulted in repos corruption.
After recovering the repos (Apache stopped) immediate corruption
repeated. After several more recoveries I gave up (with the vow to
never ever again use something below version 2 or 3 <g>). The
repos was by no means accessible anymore except for svnadmin
recover. Even the attempt to relocate to file:/// access was futile.
During these futile attempts I monitored memory use, especially of
virtual memory: it skyrocketed to its ceiling and remained there
well after the SVN server had timed out. CPU usage was at an
average of 50-70%. RAM is 144 MB, pagefile 460 MB (fixed).
The next morning after another recover the repository worked again!
No cold or warm reboot in-between but hibernation only! And
memory consumption was low: RAM usage did not go above
80MB, pagefile not above 220 MB.
Can this be a memory leak? As a non-programmer I have no real
idea what this is, but it seems so unlikely to me that a small
commit works, but directly thereafter the update of the other
working copy resulting from this not. And not once, but repeatedly
and constantly. And that _ANY_ command to the repos ends in
corruption while the HDD rotates like mad. After 35 update/commit
cycles of quite different sizes had worked flawlessly.
And that a hibernation "solves" the problem. I assume from this
that hibernation has some refreshing effect on the memory.
Hibernation is controlled by the BIOS here, not by W2K. It's a
notebook from the days before Windows learned power saving and
ACPI.
More physical memory is still on the agenda. But this skyrocketing
of memory usage (on the other machine with 1GB pagefile I got
Windows errors about too little virtual memory) implies that even
several GB physical RAM would not be sufficient in such a case.
Perforce btw suggests 1.5 KB RAM per file or 150 MB sufficient for
100,000 files. With 4500 files I am miles below of this and I would
not expect that SVN would perform that worse.
Jan Hendrik
---------------------------------------
Freedom quote:
The object and practice of liberty lies
in the limitation of governmental power.
-- Gen. Douglas MacArthur
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 23 10:37:12 2003