Bazaar

Bug #456077
Comment #12

Comment 12 for bug 456077

Revision history for this message

John A Meinel (jameinel) wrote on 2009-11-06: Re: [Bug 456077] Re: bzr branch: unacceptable slow

#12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> One more subquestion for 2): as the upgrade takes 48 hours, which is too long downtime, we'll need to design a multi-step upgrade; I guess:
> take original repo offline; copy the original repo (minutes); take the original repo online;
> upgrade the copy's format (48 hours);
> take the original repo offline; pull the original's repos changes into the copy (minutes); take the original repo online; eof.

Right. We've actually outlined that process here:
http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html?highlight=upgrade#migrating-data-to-the-new-default-format

>
> Something observed by the colleague when on-the-fly conversion happened:
> he had:
> his laptop (bzr 2.0, 2a repo) branching from our central host (bzr 1.17, 1.9-or-1.14 repo):
> - laptop: no bzr cpu use, no disk size increase
> - no network traffic
> - central host: bzr running at 100% cpu (user), increasing slowly in memory use ~450M
> So it looks like the central host (bzr 1.17) knows the 2a format and performs the conversion while the laptop waits for the converted result?
>

So bzr 1.17 does know about the 2a format, but the server does not do
the conversion. There are periods of time where the server is computing
what to send next where the client will be waiting on data.

I honestly can't say for sure what the server memory consumption profile
was w/ bzr 1.17. I would say that it really depends on how long this was
observed. If it was ~1 minute, then it would probably just be paging in
information about what needs to be sent. (That would be long, but
possible I suppose). If it was an hour, then it certainly is something
to investigate, as that is a lot longer than I would have expected.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr0TuQACgkQJdeBCYSNAAMhlgCdEZsso+8NYxZIQN4WVLcNdtz/
ImcAoM/+k9IUD6eV2zQyxNEpYV0xtDvO
=5Sqz
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GuilhemBichot wrote:
> One more subquestion for 2): as the upgrade takes 48 hours, which is too long downtime, we'll need to design a multi-step upgrade; I guess: 
> take original repo offline; copy the original repo (minutes); take the original repo online;
> upgrade the copy's format (48 hours);
> take the original repo offline; pull the original's repos changes into the copy (minutes); take the original repo online; eof.

Right. We've actually outlined that process here:
http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html?highlight=upgrade#migrating-data-to-the-new-default-format

> 
> Something observed by the colleague when on-the-fly conversion happened:
> he had:
> his laptop (bzr 2.0, 2a repo) branching from our central host (bzr 1.17, 1.9-or-1.14 repo):
> - laptop: no bzr cpu use, no disk size increase
> - no network traffic
> - central host: bzr running at 100% cpu (user), increasing slowly in memory use ~450M
> So it looks like the central host (bzr 1.17) knows the 2a format and performs the conversion while the laptop waits for the converted result?
>

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr0TuQACgkQJdeBCYSNAAMhlgCdEZsso+8NYxZIQN4WVLcNdtz/
ImcAoM/+k9IUD6eV2zQyxNEpYV0xtDvO
=5Sqz
-----END PGP SIGNATURE-----