Launchpad Fetching revisions very slow.
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
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Revision history for this message
|
#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
|
#2 |
What version of Bazaar are you running locally? (What is the output of 'bzr --version'?)
Revision history for this message
|
#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
|
#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.
bzrlib: /usr/lib/
Bazaar configuration: /home/alfa/.bazaar
Bazaar log file: /home/alfa/.bzr.log
Copyright 2005, 2006, 2007, 2008, 2009 Canonical Ltd.
http://
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
|
#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
|
#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:
See full report below:
alfa@alfa-
Using saved parent location: http://
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:/
Sourcedeps: /home/alfa/
Sourcecode: /home/alfa/
Config: ./lp-branches/
bzr: ERROR: Not a branch: "bzr+ssh:
Getting bzr-builder from lp:~launchpad-pqm/bzr-builder/trunk at revision 63
Traceback (most recent call last):
File "/home/
sys.
File "/home/
options.
File "/home/
get_
File "/home/
possible_
File "/usr/lib/
result = cloning_
File "/usr/lib/
return self._initializ
File "/usr/lib/
mode=
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
raise errors.
bzrlib.
Updating sourcecode dependencies in current local branches:
/home/
alfa@alfa-
Revision history for this message
|
#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
|
#8 |
Using mtr I can see a particular router dropping packets. Maybe launchpad should locate elsewhere.
13. ae-82-82.
ae-
ae-
ae-
14. ae-81-81.
15. ae-41-41.
ae-
ae-
16. ae-59-224.
ae-
ae-
17. ae-2-52.
18. MNET-INTERN.
19. eth0.chenet.
20. launchpad-
Revision history for this message
|
#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
|
#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.
bwing (0.0.0.0) Tue Sep 11 15:49:42 2012
Keys: Help Display mode Restart statistics Order of fields quit
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
|
#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.