Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of markphip@gmail.com designates
 209.85.161.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EA91AB7.7050903@fsn.hu>
References: <4EA7CC74.5000406@fsn.hu>
	<87y5w73mcb.fsf@stat.home.lan>
	<4EA91AB7.7050903@fsn.hu>
Date: Thu, 27 Oct 2011 07:47:56 -0400
Message-ID: 
 <CAHFaGCqSNDA=EX5ygid+ghgSc_gn6Y8h+yO9BAvQkLzFOGsxuQ@mail.gmail.com>
Subject: Re: Assertion failed and crash with 1.7.1
From: Mark Phippard <markphip@gmail.com>
To: Attila Nagy <bra@fsn.hu>
Cc: Philip Martin <philip.martin@wandisco.com>, users@subversion.apache.org
Content-Type: multipart/alternative; boundary=00151748e09cf3d6b604b046577f

--00151748e09cf3d6b604b046577f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy <bra@fsn.hu> wrote:

>  On 10/26/11 15:37, Philip Martin wrote:
>
> Attila Nagy <bra@fsn.hu> <bra@fsn.hu> writes:
>
>
>  I'm trying to update a working copy of some tens of GBs with svn 1.7.1
>
>  Did you upgrade with 1.7.0 or 1.7.1?
>
>  I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
> currently using.
> The upgrade took nearly one week (I can't afford a clean checkout, because
> I have to preserve the files' inode numbers), at the start it was running
> very fast, and at the end of the week it could print a new directory in
> every 8-10 seconds, while the svn processes CPU usage was 100%.
> The disks weren't touched, it seems that even with a database completely in
> the OS's buffer cache the SQL operations are pretty slow with a lot of
> files.
> Could it be because some indexes are missing (or not optimized for this
> amount of files), or it is what we could get from SQLite?
>

I can see where having all that RAM could help greatly when the database is
being read, but I do not see how it would help when we are writing to the
database.  I would imagine the database does stuff to flush itself to disk
whenever a transaction is committed.  I thought this was why we see 1.7
slower than other versions via NFS, even on small working copies where the
database would fit in anyones RAM.

I would imagine svn upgrade is almost entirely writes and I recall it does
quite a few transactions.  So couldn't the linear slow down just be based on
the growth in the amount of bytes that are written to disk each time?

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

--00151748e09cf3d6b604b046577f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bra@fsn.hu">bra@fsn.hu</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex;">

 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im">
    On 10/26/11 15:37, Philip Martin wrote:
    <blockquote type=3D"cite">
      <pre>Attila Nagy <a href=3D"mailto:bra@fsn.hu" target=3D"_blank">&lt;=
bra@fsn.hu&gt;</a> writes:

</pre>
      <blockquote type=3D"cite">
        <pre>I&#39;m trying to update a working copy of some tens of GBs wi=
th svn 1.7.1
</pre>
      </blockquote>
      <pre>Did you upgrade with 1.7.0 or 1.7.1?</pre>
    </blockquote></div>
    I&#39;ve upgraded the WC with 1.7.0, then switched to 1.7.1, which I=
9;m
    currently using.<br>
    The upgrade took nearly one week (I can&#39;t afford a clean checkout,
    because I have to preserve the files&#39; inode numbers), at the start
    it was running very fast, and at the end of the week it could print
    a new directory in every 8-10 seconds, while the svn processes CPU
    usage was 100%.<br>
    The disks weren&#39;t touched, it seems that even with a database
    completely in the OS&#39;s buffer cache the SQL operations are pretty
    slow with a lot of files.<br>
    Could it be because some indexes are missing (or not optimized for
    this amount of files), or it is what we could get from SQLite?</div></b=
lockquote><div><br>I can see where having all that RAM could help greatly w=
hen the database is being read, but I do not see how it would help when we =
are writing to the database.=A0 I would imagine the database does stuff to =
flush itself to disk whenever a transaction is committed.=A0 I thought this=
 was why we see 1.7 slower than other versions via NFS, even on small worki=
ng copies where the database would fit in anyones RAM.<br>
<br clear=3D"all">I would imagine svn upgrade is almost entirely writes and=
 I recall it does quite a few transactions.=A0 So couldn&#39;t the linear s=
low down just be based on the growth in the amount of bytes that are writte=
n to disk each time?<br>
</div></div><br>-- <br>Thanks<br><br>Mark Phippard<br><a href=3D"http://mar=
kphip.blogspot.com/">http://markphip.blogspot.com/</a><br>

--00151748e09cf3d6b604b046577f--