You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gert Kello <ge...@gmail.com> on 2016/01/28 10:54:14 UTC
Svn 1.9 repository 20% bigger than svn 1.8 repository
Hi.
I have a svn 1.9 repository, created with svnsync, that has ~150000
revisions and size about 45 GB. Due to some issues in svn-all-fast-export I
wanted to have svn 1.8 version repository so I downgraded it by doing
svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that
the size of v 1.8 repository is "only" 37.5 GB
I tried to compare content of db\revs folder: some files are bigger in 1.8
repo, some in 1.9 repo.
Now I'm wondering:
1. Is such size increase expected for 1.9 repository? I read that 1.9 was
aimed at speed optimizations, but 20% size increase compared to 1.8 sounds
pretty big...
2. Or is my "dumped and reloaded 1.8" broken somehow? How could I verify?
(dump revisions one by one and compare? Or is there any better way?)
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
> > Which method did you use to write during sync:
> > > file, svn or http?
> > >
> >
> > file:///
>
> This makes me wonder if you used file:// on top of a network drive of
> some kind? SQlite is known to have problems with network drives (as
> hinted at in http://sqlite.org/faq.html#q5).
>
Well, it is virtual machine somewhere in our server rack. Really not sure
what is the underlying hardware. But for the virtual machine itself it is
"local" disk.
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 29, 2016 at 12:42:53PM +0200, Gert Kello wrote:
> Anything special to look for? Or should we assume
> "antivirus or something else opened the file so that svnsync was unable to
> write it"?
>
> > Which method did you use to write during sync:
> > file, svn or http?
> >
>
> file:///
This makes me wonder if you used file:// on top of a network drive of
some kind? SQlite is known to have problems with network drives (as
hinted at in http://sqlite.org/faq.html#q5).
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@wandisco.com>.
Gert Kello <ge...@gmail.com> writes:
> The revision file write times:
> 91448 -> 13:16:44
> 91449 -> 13:16:44
> 91450 -> 13:16:44
> 91451 -> 13:16:48
> 91452 -> 13:16:48
> 91452 -> 13:17:00
>
> 91450 was the last one that has data is sqlite database.
> 91451 has nothing in 1.8 db neither
> 91452 has one entry in 1.8 db.
>
> So the 10 sec timeout is possible. However, I peeked into the event logs;
> seems like our server is logging all process starts/ends. I see that at
> 13:16:48, cmd.exe process was started. 13:16:49 a wermgr.exe is started -
> its windows error reporting tool. And 13:16.50 a rundll32.exe is started.
> The wermgr.exe ends at 13:16.50 and rundll32.exe at 13.16.55, and after
> that, next cmd.exe starts at 13:16:59
>
> For me it seems those "cmd.exe" starts are related to svnsync, at least
> there are many of those during sync. I tried to find the error report
> generated but failed. Most likely do not know how to search it correctly.
Subversion has repository handles and only attempts to open the
rep-cache once for each repository handle, the result is cached in the
handle. Running svnsync could open multiple handles but usually reuses
a single handle. In the case of file:// the svnsync client simply
reuses the handle. In the case of svn:// and http:// the svnsync client
does the sync over one connection and the server caches the handle for
the connection.
If the rep-cache fails to open when first accessed then this failure can
be cached for the entire svnsync run with the result that the entire
svnsync run will do no deduplication. This is probably a good thing if
the problem is a corrupt file that will always fail to work. It is less
good for a transient problem cause by interference from some Windows
anti-virus/indexing.
--
Philip Martin
WANdisco
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
Guten Tag Gert Kello,
> am Freitag, 29. Januar 2016 um 12:50 schrieben Sie:
>
> > For me it seems those "cmd.exe" starts are related to svnsync, at
> > least there are many of those during sync.
>
> Sounds like the hook call of "pre-revprop-change", doesn't it?
>
Yes, that's so obvious now, when You tell it.. Makes me feel stupid. :)
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Gert Kello,
am Freitag, 29. Januar 2016 um 12:50 schrieben Sie:
> For me it seems those "cmd.exe" starts are related to svnsync, at
> least there are many of those during sync.
Sounds like the hook call of "pre-revprop-change", doesn't it?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
I managed to replay only to Philip first, so I have a chance to write
changed/better answer to list :)
> Should I look at some svn oog information about the revisions where is
> > started to fail? Anything special to look for? Or should we assume
> > "antivirus or something else opened the file so that svnsync was unable
> to
> > write it"? The sync for this rev has been executing in the middle of day
> so
> > it is possible I tried to peek "how big the repo is at disk".
>
> The SQLite code expects there to be contention for the file and has a
> timeout (10s as I recall). In your case something appears to have
> blocked access for an extended period of time.
>
>
The revision file write times:
91448 -> 13:16:44
91449 -> 13:16:44
91450 -> 13:16:44
91451 -> 13:16:48
91452 -> 13:16:48
91452 -> 13:17:00
91450 was the last one that has data is sqlite database.
91451 has nothing in 1.8 db neither
91452 has one entry in 1.8 db.
So the 10 sec timeout is possible. However, I peeked into the event logs;
seems like our server is logging all process starts/ends. I see that at
13:16:48, cmd.exe process was started. 13:16:49 a wermgr.exe is started -
its windows error reporting tool. And 13:16.50 a rundll32.exe is started.
The wermgr.exe ends at 13:16.50 and rundll32.exe at 13.16.55, and after
that, next cmd.exe starts at 13:16:59
For me it seems those "cmd.exe" starts are related to svnsync, at least
there are many of those during sync. I tried to find the error report
generated but failed. Most likely do not know how to search it correctly.
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@wandisco.com>.
Gert Kello <ge...@gmail.com> writes:
> They are identical up to rev 91450. And then there's a large gap between
> revisions 91450 and 155838. 155838 seems to be where new "svnsync" was
> started, there's gap of time stamps in revision files.
> 91450 does not seem to be special in term of sync sequence. About 60
> revisions within same minute, previous two in same second, next one 4
> seconds later
The rep-cache failure almost certainly explains the size difference.
> (How does svnsync work? "find last rev at source and sync up to that" or
> "sync while next revision present in source"? If latter then first sync
> failed for some reason... If first then it probably ran till completion.
> But does it actually matter?)
svnsync uses revision properties on r0 that get updated as the sync
proceeds:
svnlook proplist -v --revprop -r0 path/to/repo
> Should I look at some svn oog information about the revisions where is
> started to fail? Anything special to look for? Or should we assume
> "antivirus or something else opened the file so that svnsync was unable to
> write it"? The sync for this rev has been executing in the middle of day so
> it is possible I tried to peek "how big the repo is at disk".
The SQLite code expects there to be contention for the file and has a
timeout (10s as I recall). In your case something appears to have
blocked access for an extended period of time.
--
Philip Martin
WANdisco
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
On 29 January 2016 at 11:52, Philip Martin <ph...@wandisco.com>
wrote:
> > How can I test if the 1.9 has really corrupt sqlite db file? For me it
> > seems that it still gets updates (i.e. when I bring in new revisions with
> > svnsync.)
>
> Check the index with:
>
> sqlite3 db/rep-cache.db "pragma integrity_check"
>
Says "ok"
> Compare the ordered list:
>
> sqlite3 db/rep-cache.db "select hash,revision from rep_cache order by
> revision"
>
> with the 1.8 list and you may be able to identify which revisions are
> missing from the 1.9 rep-cache. There isn't any way to fix the missing
>
They are identical up to rev 91450. And then there's a large gap between
revisions 91450 and 155838. 155838 seems to be where new "svnsync" was
started, there's gap of time stamps in revision files.
91450 does not seem to be special in term of sync sequence. About 60
revisions within same minute, previous two in same second, next one 4
seconds later
(How does svnsync work? "find last rev at source and sync up to that" or
"sync while next revision present in source"? If latter then first sync
failed for some reason... If first then it probably ran till completion.
But does it actually matter?)
> deduplication other than a dump/load, but it would be interesting to
> find out why it failed.
Should I look at some svn oog information about the revisions where is
started to fail? Anything special to look for? Or should we assume
"antivirus or something else opened the file so that svnsync was unable to
write it"? The sync for this rev has been executing in the middle of day so
it is possible I tried to peek "how big the repo is at disk".
> Which method did you use to write during sync:
> file, svn or http?
>
file:///
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@wandisco.com>.
Gert Kello <ge...@gmail.com> writes:
> You are correct, there are 341378 entries in 1.9 file vs 499837 in 1.8
>
> And the failing de-duplication seems to be reason indeed. I have located
> one revision which is 112 MB in 1.9 repository but 15 kB in 1.8 repo. The
> commit is "add" (without history) of several files, some binary, some text,
> total of 900+ MB. Binary files are zip, xls and xlsx, ~92 MB, text files
> txt, xml, csv, ~840 MB
>
> How can I test if the 1.9 has really corrupt sqlite db file? For me it
> seems that it still gets updates (i.e. when I bring in new revisions with
> svnsync.)
Check the index with:
sqlite3 db/rep-cache.db "pragma integrity_check"
Compare the ordered list:
sqlite3 db/rep-cache.db "select hash,revision from rep_cache order by revision"
with the 1.8 list and you may be able to identify which revisions are
missing from the 1.9 rep-cache. There isn't any way to fix the missing
deduplication other than a dump/load, but it would be interesting to
find out why it failed. Which method did you use to write during sync:
file, svn or http?
--
Philip Martin
WANdisco
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
On 29 January 2016 at 02:40, Philip Martin <ph...@wandisco.com>
wrote:
> > rep-cache.db files are different, 39.7 MB in 1.9 and 58.4 MB in 1.8
>
> The rep-cache is an SQLite file that contains a map of checksums to
> revisions and if stops working then Subversion will continue to allow
> commits but will do less, or no, deduplication.
>
> You can see how many entries there are with:
>
> sqlite3 repo/db/rep-cache.db "select count(*) from rep_cache order"
>
> You can see the entries with:
>
> sqlite3 repo/db/rep-cache.db "select hash,revision from rep_cache order
> by revision"
>
> I suspect 1.9 will show fewer entries, or many refuse to return any
> results at all if the file is corrupt.
>
You are correct, there are 341378 entries in 1.9 file vs 499837 in 1.8
And the failing de-duplication seems to be reason indeed. I have located
one revision which is 112 MB in 1.9 repository but 15 kB in 1.8 repo. The
commit is "add" (without history) of several files, some binary, some text,
total of 900+ MB. Binary files are zip, xls and xlsx, ~92 MB, text files
txt, xml, csv, ~840 MB
How can I test if the 1.9 has really corrupt sqlite db file? For me it
seems that it still gets updates (i.e. when I bring in new revisions with
svnsync.)
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> You can see how many entries there are with:
>
> sqlite3 repo/db/rep-cache.db "select count(*) from rep_cache order"
That should be:
sqlite3 repo/db/rep-cache.db "select count(*) from rep_cache"
--
Philip
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@wandisco.com>.
Gert Kello <ge...@gmail.com> writes:
> rep-cache.db files are different, 39.7 MB in 1.9 and 58.4 MB in 1.8
The rep-cache is an SQLite file that contains a map of checksums to
revisions and if stops working then Subversion will continue to allow
commits but will do less, or no, deduplication.
You can see how many entries there are with:
sqlite3 repo/db/rep-cache.db "select count(*) from rep_cache order"
You can see the entries with:
sqlite3 repo/db/rep-cache.db "select hash,revision from rep_cache order by revision"
I suspect 1.9 will show fewer entries, or many refuse to return any
results at all if the file is corrupt.
--
Philip Martin
WANdisco
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
On 28 January 2016 at 14:37, Philip Martin <ph...@wandisco.com>
wrote:
> > I have a svn 1.9 repository, created with svnsync, that has ~150000
> > revisions and size about 45 GB. Due to some issues in
> svn-all-fast-export I
> > wanted to have svn 1.8 version repository so I downgraded it by doing
> > svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that
> > the size of v 1.8 repository is "only" 37.5 GB
> > I tried to compare content of db\revs folder: some files are bigger in
> 1.8
> > repo, some in 1.9 repo.
>
> That is not the expected behaviour, 1.9 would normally be smaller. Can
> you identify where the difference lies? For example: are the HEAD
> revisions the same? Are the db/revprops/ directories about the same
> size? Are the db/revs/ directories about the same size? Are the
> db/rep-cache.db files about the same size?
>
> the db/revpops are about the same, 23.7 MB in 1.9 and 23.8 MB in 1.8
rep-cache.db files are different, 39.7 MB in 1.9 and 58.4 MB in 1.8
The main difference is in sizes of db/revs folders
> You can run
>
> svnlook tree path/to/repo
>
> to get a listing of all the paths visible in HEAD, you should get the
> same list for 1.8 and 1.9.
>
>
That gives identical results for both. Text file (with --full-paths) size
is 272 MB.
> 1.9 provides
>
> svnfsfs stats path/to/repo
>
> which you can run on both the 1.8 and 1.9 repositories.
>
>
I'm using TortoiseSvn binaries, seems like this is not part of that
distribution. I'll look at it later (tomorrow).
Gert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
On 28 January 2016 at 14:47, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > > I have a svn 1.9 repository, created with svnsync, that has ~150000
> > > revisions and size about 45 GB. Due to some issues in
> svn-all-fast-export I
> > > wanted to have svn 1.8 version repository so I downgraded it by doing
> > > svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised
> that
> > > the size of v 1.8 repository is "only" 37.5 GB
> > > I tried to compare content of db\revs folder: some files are bigger in
> 1.8
> > > repo, some in 1.9 repo.
>
> Just to be sure: that 1.9 repository was recently created with 1.9 and then
> loaded via svnsync?
>
>
Exactly.
> Did you try to svnadmin load the same repository into a new 1.9 repository?
> (I would be interested in that result). 1.9 should also be able to create
> repositories compatible with older versions.
>
I know about this ability... But still preferred to use 1.8 binaries. If
anyone is interested and I have time, could try to do the load with 1.9
binaries into 1.8 repository.
At the moment I'm loading 1.8 repo into 1.9 one via dump|load. I'll look if
starting parallel dump|load would be Ok for hardware, if not I'll start it
after this one completes.
> You might have a very interesting testcase at hand :-)
>
> But with such a size repository it might be hard to test different
> variants.
>
>
That's true... Well, dump & load from 1.9 to 1.8 took ~14.5 hours so some
combinations can be tested.
Gert
RE: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: donderdag 28 januari 2016 13:38
> To: Gert Kello <ge...@gmail.com>
> Cc: users@subversion.apache.org
> Subject: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
>
> Gert Kello <ge...@gmail.com> writes:
>
> > I have a svn 1.9 repository, created with svnsync, that has ~150000
> > revisions and size about 45 GB. Due to some issues in
svn-all-fast-export I
> > wanted to have svn 1.8 version repository so I downgraded it by doing
> > svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that
> > the size of v 1.8 repository is "only" 37.5 GB
> > I tried to compare content of db\revs folder: some files are bigger in
1.8
> > repo, some in 1.9 repo.
Just to be sure: that 1.9 repository was recently created with 1.9 and then
loaded via svnsync?
Or was it upgraded from previous versions?
Did you try to svnadmin load the same repository into a new 1.9 repository?
(I would be interested in that result). 1.9 should also be able to create
repositories compatible with older versions.
You might have a very interesting testcase at hand :-)
But with such a size repository it might be hard to test different variants.
Bert
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Philip Martin <ph...@wandisco.com>.
Gert Kello <ge...@gmail.com> writes:
> I have a svn 1.9 repository, created with svnsync, that has ~150000
> revisions and size about 45 GB. Due to some issues in svn-all-fast-export I
> wanted to have svn 1.8 version repository so I downgraded it by doing
> svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle. I was surprised that
> the size of v 1.8 repository is "only" 37.5 GB
> I tried to compare content of db\revs folder: some files are bigger in 1.8
> repo, some in 1.9 repo.
>
> Now I'm wondering:
> 1. Is such size increase expected for 1.9 repository? I read that 1.9 was
> aimed at speed optimizations, but 20% size increase compared to 1.8 sounds
> pretty big...
> 2. Or is my "dumped and reloaded 1.8" broken somehow? How could I verify?
> (dump revisions one by one and compare? Or is there any better way?)
That is not the expected behaviour, 1.9 would normally be smaller. Can
you identify where the difference lies? For example: are the HEAD
revisions the same? Are the db/revprops/ directories about the same
size? Are the db/revs/ directories about the same size? Are the
db/rep-cache.db files about the same size?
You can run
svnlook tree path/to/repo
to get a listing of all the paths visible in HEAD, you should get the
same list for 1.8 and 1.9.
1.9 provides
svnfsfs stats path/to/repo
which you can run on both the 1.8 and 1.9 repositories.
--
Philip Martin
WANdisco
Re: svn-all-fast-export crash (was: Re: Svn 1.9 repository 20% bigger than svn 1.8 repository)
Posted by Ryan Schmidt <su...@ryandesign.com>.
> On Jan 28, 2016, at 1:54 AM, Gert Kello <ge...@gmail.com> wrote:
>
> I have a svn 1.9 repository, created with svnsync, that has ~150000 revisions and size about 45 GB. Due to some issues in svn-all-fast-export I wanted to have svn 1.8 version repository so I downgraded it by doing svnadmin (v 1.9) dump /svnadmin (v 1.8) load cycle.
Gert,
I was going to mention that I'm also trying to use svn-all-fast-export with a repository of ~145000 revisions, created by svnsync 1.9 from an older repository (which was at one point converted from cvs), and that I'm also having issues, specifically svn-all-fast-export crashes after every import, and branches and tags don't get imported. Then I noticed that you already commented on the bug report I filed about that:
https://github.com/svn-all-fast-export/svn2git/issues/5
I'll try doing svn-all-fast-export with Subversion 1.8 libraries instead to confirm if that fixes it for me too.
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Gert Kello <ge...@gmail.com>.
You mean the content of db\transactions and db\txn-protorevs folders? They
are empty. svnadmin lstxns shows nothing as well.
(I'm on windows machine, if it matters. Forgot to mention on first e-mail)
Gert
On 28 January 2016 at 14:20, Yves Martin <ym...@gmail.com> wrote:
> Hello,
>
> Have you checked disk space consumed by "pending" transactions
> (db/transactions) in your original 1.9 repository ?
> To clean up, use svnadmin lstxns and rmtxns.
>
> Hope this helps
> --
> Yves Martin
>
Re: Svn 1.9 repository 20% bigger than svn 1.8 repository
Posted by Yves Martin <ym...@gmail.com>.
Hello,
Have you checked disk space consumed by "pending" transactions
(db/transactions) in your original 1.9 repository ?
To clean up, use svnadmin lstxns and rmtxns.
Hope this helps
--
Yves Martin