tickets #108656
closed
- Category set to Mirrors
- Status changed from New to Feedback
- Assignee set to pjessen
- Private changed from Yes to No
Initial observation - there is no reason why any repo or directories should be slower than any other. However, mirrors of those might differ a lot.
To enable me to tell which mirrors are being allocated/proposed, please provide the IP address of the client.
msvec wrote:
FTR, the download speed is super-slow again.
wget http://download.opensuse.org/update/leap/15.4/sle/repodata/83c1a43da05d5115eccbc5c4c7dd7bad7808fa3627d0fae4ad4aeff47d6d1380-primary.xml.gz
wget gives 212KB/s, but zypper gets stuck on this forever:
"Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15' metadata "
Michal
In order to do anything at all about this, I really have to know from where, i.e from which client address. Alternatively, post which exact mirror it is that is being slow.
Regardless, it is unlikely we can do anything, it is a matter been the client and the mirror. For myself, I get 18Mb/s for that file, from downloadcontent.o.o.
- Status changed from Feedback to New
wget -vvv http://downloadcontent.opensuse.org/update/leap/15.3/sle/repodata/fd627cc03e1dc5092c31ad2cd102988dc530e41bedfc4588681dfe707b473c43-primary.xml.gz
--2022-03-26 10:46:14-- http://downloadcontent.opensuse.org/update/leap/15.3/sle/repodata/fd627cc03e1dc5092c31ad2cd102988dc530e41bedfc4588681dfe707b473c43-primary.xml.gz
Resolving downloadcontent.opensuse.org (downloadcontent.opensuse.org)... 2001:67c:2178:8::27
Connecting to downloadcontent.opensuse.org (downloadcontent.opensuse.org)|2001:67c:2178:8::27|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 74688428 (71M) [application/octet-stream]
Saving to: ‘fd627cc03e1dc5092c31ad2cd102988dc530e41bedfc4588681dfe707b473c43-primary.xml.gz’
fd627cc03e1dc5092c31ad2cd102988dc530e41 100%[============================================================================>] 71.23M 22.0MB/s in 3.3s
2022-03-26 10:46:17 (21.3 MB/s) - ‘fd627cc03e1dc5092c31ad2cd102988dc530e41bedfc4588681dfe707b473c43-primary.xml.gz’ saved [74688428/74688428]
ml.gz’ saved [74688428/74688428]
Currently running at ~150-200KB/s
It is possible that pontifex was very heavily loaded when you tried this yesterday, but it is not easy to say. From my download above, it is clear that pontifex has the ability to serve 22MB/sec. I tried another client machine, and got almost 50Mb/sec.
I have no idea if this might be involved, but I'll add it anyway. For rsync.o.o, updates are being pushed to us, but for some reason, backports/ and sle/ are not being pushed. See #100506. Regardless, that is only one mirror, but we simply cannot get updates/ sync'ed so quickly, so sometimes downloads have to revert to downloadcontent.o.o.
I am evaluating (almost) complete switch from MirrorBrain to MirrorCache today, so it may work better (or worse).
andriinikitin wrote:
I am evaluating (almost) complete switch from MirrorBrain to MirrorCache today, so it may work better (or worse).
I wonder how that is going to affect the download speed from rsync.o.o :-)
- Assignee changed from pjessen to andriinikitin
pjessen wrote:
I wonder how that is going to affect the download speed from rsync.o.o :-)
So I'd say 3 problems can be considered in this ticket:
- download speed from rsync.o.o
- slowness (of zypper) when downloading *primary.xml.gz from http://download.opensuse.org/update/leap/15.3/sle/repodata/
- the fact that http://download.opensuse.org/update/leap/15.3/sle/repodata/ is released several times per day, requiring every user to download (and for zypper to process it) ~90M in almost every
zypper refresh
command.
I'd say that it is unlikely that we can do something about 3. in short run, but imho the community definitely should escalate it and maybe challenge release managers(?). (Although I heard that zypper team is working on allowing download of delta for -primary.xml.gz instead of full download, which definitely can address this problem, unless I am mistaken here).
Regarding 2. : Today I enabled MirrorCache for all .rpm and .xml.gz requests and my testing shows good speed - can anybody confirm it?
- Status changed from New to Resolved
It looks this is resolved now , can it be closed?
Also available in: Atom
PDF