Launchpad Fetching revisions very slow.

Asked by bunjee

Hi Guys,

I'm currently installing launchpad on my personal server.

I'm at this step:

Making local branch of Launchpad trunk, this may take a while...
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data. See "bzr help launchpad-login".
[#########| ] 34856KB 1381KB/s | Fetching revisions:Inserting stream

For some reason the download is super slow and even seems to freezes the system.

Has anyone had this kind of issue?
Can we download launchpad sources from another place?

Thanks.

Question information

Language:
English Edit question
Status:
Answered
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alfa (maximsok) said :
#1

I have the same problem :( It's already running > 12 hours. I have Ubuntu 9.10 - the Karmic Koala and pretty fast connections (10 -100 Mb/s)

After 14 hours it finally crashed with an error:
./rocketfuel-setup: line 299: 4083 Killed bzr branch lp:~launchpad-pqm/launchpad/devel $LP_TRUNK_NAME
ERROR: Unable to create local copy of Rocketfuel trunk

Revision history for this message
Karl Fogel (kfogel) said :
#2

What version of Bazaar are you running locally? (What is the output of 'bzr --version'?)

Revision history for this message
Robert Collins (lifeless) said :
#3

The rocketfuel script deliberately uses http, and http mode doesn't stream, does many more roundtrips and has to cache more data in ram.

So you are probably just seeing excessive swap activity on your machines.

Revision history for this message
Alfa (maximsok) said :
#4

I use the following version:

Bazaar (bzr) 2.0.4
  Python interpreter: /usr/bin/python 2.6.4
  Python standard library: /usr/lib/python2.6
  Platform: Linux-2.6.31-19-generic-i686-with-Ubuntu-9.10-karmic
  bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
  Bazaar configuration: /home/alfa/.bazaar
  Bazaar log file: /home/alfa/.bzr.log

Copyright 2005, 2006, 2007, 2008, 2009 Canonical Ltd.
http://bazaar-vcs.org/

bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

Revision history for this message
Tim Penhey (thumper) said :
#5

What do you get if you do `bzr lp-login`?

You need to set your launchpad id as the lp-login for bzr and make sure you have an SSH key set for your user on Launchpad. This will mean you use the bzr+ssh protocol, which is much faster.

Revision history for this message
Alfa (maximsok) said :
#6

Thanks a lot Karl, Robert, and Tim!

The slowness problem was due to small amount of available memory (400 MB on Sun Virtual Box). After I increased it to 1 GB bazaar was able to pull devel trunk (it seems it needs around 700 MB).

Than I had problems pulling dependencies, but after, as Tim suggested, I uploaded my public ssh key to launchpad rocketfuel-setup went on to compilation stage. (for bzr lp-login I now get 'maximsok')

But I still had problem getting shipit trunk (from rocketfuel-setup as well as from rocketfuel-get):

bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/".

See full report below:

alfa@alfa-ukon:~/launchpad$ ./lp-branches/devel/utilities/rocketfuel-get
Using saved parent location: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/
No revisions to pull.
Tree is up to date at revision 120.
Updating sourcecode dependencies in rocketfuel:

  NOTE: Each sourcedep may take a while; please be patient.

  ALSO NOTE: You can ignore any warnings you see below about how
  'You have not informed bzr of your Launchpad ID ...' etc.
  See https://bugs.edge.launchpad.net/bzr/+bug/401617 for why.

    Sourcedeps: /home/alfa/launchpad/lp-sourcedeps/sourcecode
        Sourcecode: /home/alfa/launchpad/lp-sourcedeps/sourcecode
        Config: ./lp-branches/devel/utilities/sourcedeps.conf
bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/".
        Getting bzr-builder from lp:~launchpad-pqm/bzr-builder/trunk at revision 63
Traceback (most recent call last):
  File "/home/alfa/launchpad/lp-branches/devel/utilities/update-sourcecode", line 18, in <module>
    sys.exit(sourcecode.main(sys.argv))
  File "/home/alfa/launchpad/lp-branches/devel/lib/devscripts/sourcecode.py", line 292, in main
    options.public_only, options.tip, options.dry_run)
  File "/home/alfa/launchpad/lp-branches/devel/lib/devscripts/sourcecode.py", line 244, in update_sourcecode
    get_branches(sourcecode_directory, new, possible_transports, tip)
  File "/home/alfa/launchpad/lp-branches/devel/lib/devscripts/sourcecode.py", line 176, in get_branches
    possible_transports=possible_transports)
  File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1151, in sprout
    result = cloning_format.initialize_on_transport(target_transport)
  File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1863, in initialize_on_transport
    return self._initialize_on_transport_vfs(transport)
  File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1984, in _initialize_on_transport_vfs
    mode=temp_control._dir_mode)
  File "/usr/lib/python2.5/site-packages/bzrlib/transport/local.py", line 325, in mkdir
    self._mkdir(self._abspath(relpath), mode=mode)
  File "/usr/lib/python2.5/site-packages/bzrlib/transport/local.py", line 321, in _mkdir
    self._translate_error(e, abspath)
  File "/usr/lib/python2.5/site-packages/bzrlib/transport/__init__.py", line 314, in _translate_error
    raise errors.FileExists(path, extra=e)
bzrlib.errors.FileExists: File exists: u'/home/alfa/launchpad/lp-sourcedeps/sourcecode/bzr-builder/.bzr': [Errno 17] File exists: '/home/alfa/launchpad/lp-sourcedeps/sourcecode/bzr-builder/.bzr'
Updating sourcecode dependencies in current local branches:
    /home/alfa/launchpad/lp-branches/devel
alfa@alfa-ukon:~/launchpad$

Revision history for this message
Jacopo A (jacopo-a) said :
#7

I've got the same problem but I'll try to do what Tim suggested. I hate my slow connection :(
There is no other way to get the code?

Revision history for this message
jordg (gbj) said :
#8

Using mtr I can see a particular router dropping packets. Maybe launchpad should locate elsewhere.

13. ae-82-82.csw3.NewYork1.Level3.net 0.0% 31 305.3 299.2 252.1 320.5 13.7
    ae-92-92.csw4.NewYork1.Level3.net
    ae-62-62.csw1.NewYork1.Level3.net
    ae-72-72.csw2.NewYork1.Level3.net
14. ae-81-81.ebr1.NewYork1.Level3.net 0.0% 31 295.9 297.0 294.5 306.8 3.3
15. ae-41-41.ebr2.London1.Level3.net 0.0% 30 319.5 319.9 318.4 340.1 3.8
    ae-43-43.ebr2.London1.Level3.net
    ae-42-42.ebr2.London1.Level3.net
16. ae-59-224.csw2.London1.Level3.net 0.0% 30 322.2 330.4 319.1 373.1 17.9
    ae-57-222.csw2.London1.Level3.net
    ae-58-223.csw2.London1.Level3.net
17. ae-2-52.edge4.London1.Level3.net 93.1% 30 366.8 366.6 366.4 366.8 0.3
18. MNET-INTERN.edge4.London1.Level3.net 0.0% 30 326.4 326.6 325.4 330.3 1.1
19. eth0.chenet.canonical.com 3.3% 30 330.9 332.0 330.0 335.2 1.3
20. launchpad-net.nutmeg.canonical.com 0.0% 30 319.6 319.4 318.1 322.6 0.8

Revision history for this message
Chris Stratford (chris-gondolin) said :
#9

The packet loss you're seeing there may just have been a transient problem at Level3, as it doesn't seem to be there now:

 8. 87.237.20.246 0.0% 10 15.0 22.7 14.8 61.5 16.5
 9. 193.251.254.33 0.0% 10 14.9 37.8 14.6 103.9 37.8
10. 193.251.242.238 0.0% 10 18.2 27.6 14.8 59.4 14.7
    193.251.242.21
    193.251.243.33
    193.251.242.182
    193.251.241.33
11. 4.68.111.65 0.0% 10 16.1 15.7 14.9 16.4 0.5
12. 4.69.166.129 0.0% 10 22.6 35.5 15.6 105.0 33.2
13. 4.69.139.74 0.0% 10 14.9 23.6 14.9 56.2 13.0
14. 212.113.14.198 0.0% 10 26.1 18.9 15.0 26.1 3.1
15. 91.189.88.133 0.0% 10 16.1 24.5 15.0 102.2 27.3
16. 91.189.89.222 0.0% 9 16.8 28.1 15.6 73.8 21.6

Revision history for this message
jordg (gbj) said :
#10

I still have the issue. I do not believe that the problem is transient. Every time GMT+10 I use mtr it has packet loss. Always the same router. You provider needs to be notified.

                                           My traceroute [v0.80]
bwing (0.0.0.0) Tue Sep 11 15:49:42 2012
Keys: Help Display mode Restart statistics Order of fields quit
                                                                    Packets Pings
 Host Loss% Snt Last Avg Best Wrst StDev
 1. 192.168.0.254 0.0% 29 0.2 0.2 0.1 0.2 0.0
 2. 203.215.7.251 0.0% 29 20.4 20.5 19.6 25.0 1.0
 3. 203.215.6.10 0.0% 29 20.1 20.9 20.1 25.5 1.0
 4. 203.215.20.102 0.0% 29 102.6 39.3 30.6 102.6 19.9
 5. 134.159.126.189 0.0% 29 31.3 31.5 30.2 36.0 1.0
 6. 202.84.223.1 0.0% 29 32.1 36.4 30.9 143.7 21.1
 7. 202.84.144.185 0.0% 29 187.8 193.1 187.8 266.3 15.9
 8. 202.84.251.62 0.0% 29 186.6 243.5 185.8 539.4 96.5
 9. 134.159.62.198 0.0% 29 229.3 233.6 228.1 277.5 12.5
10. 4.69.152.126 0.0% 29 183.0 183.5 181.6 189.1 1.7
11. 4.69.153.5 0.0% 29 184.7 184.6 183.4 187.5 0.9
12. 4.69.135.186 0.0% 29 297.9 298.8 297.9 304.1 1.1
13. 4.69.148.46 0.0% 29 297.7 298.4 296.9 310.8 2.6
14. 4.69.134.77 0.0% 29 251.5 251.2 249.5 254.5 0.9
15. 4.69.137.73 0.0% 28 320.1 321.1 319.5 322.7 0.8
16. 4.69.153.138 0.0% 28 364.7 368.1 363.7 375.6 4.1
17. 4.69.139.106 88.9% 28 366.7 366.8 366.7 366.9 0.1
18. 212.113.14.198 0.0% 28 327.2 326.8 325.3 330.4 1.1
19. 91.189.88.133 0.0% 28 328.0 328.2 327.0 331.3 0.9
20. 91.189.95.84 0.0% 28 324.8 324.7 323.7 328.0 1.0

Revision history for this message
Nick Moffitt (nick-moffitt) said :
#11

There are two types of traffic an IP router must handle: the traffic it is routing (packets from you, say, to launchpad.net) and traffic to the router's management interface itself. When you run mtr, it sends packets with deliberately short lifespans so that one of the intervening routers must report the death of the packet from its management IP.

Note that the routers after this one show 0.0% loss. These packets necessarily make it through the "problem" router without any packet loss, and the routers behind are able to respond to you with perfect fidelity. This exonerates the L3 router in question.

This router you're concerned about is likely too busy routing traffic to respond to diagnostic probes from arbitrary people on the Internet. This is unrelated to any network performance problems you may experience.

Can you help with this problem?

Provide an answer of your own, or ask bunjee for more information if necessary.

To post a message you must log in.