I’m encountering an issue using Nexus Repository Manager as a yum proxy for AlmaLinux (https://repo.almalinux.org/almalinux/). When I run yum update (yum/dnf), the metadata downloads are often extremely slow or eventually fail. Here’s an example of what I see:
# yum update
NexusAlmaYumProxy - baseos 16 MB/s | 18 MB 00:01
NexusAlmaYumProxy - appstream 526 kB/s | 16 MB 00:30
NexusAlmaYumProxy - extras 2.1 kB/s | 13 kB 00:06
...
NexusAlmaYumProxy - baseos 0.0 B/s | 0 B 01:41
Errors during downloading metadata for repository 'baseos':
- Curl error (28): Timeout was reached for http://my-internal-server:8081/repository/yum-almalinux-proxy/9/BaseOS/x86_64/os/repodata/repomd.xml [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
- Status code: 502 for http://my-internal-server:8081/repository/yum-almalinux-proxy/9/BaseOS/x86_64/os/repodata/repomd.xml (IP: XXX.XXX.XXX.XXX)
Error: Failed to download metadata for repo 'baseos': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
These slow downloads and errors often happen when provisioning a VM via Ansible. Has anyone experienced similar yum metadata slowdowns or timeouts with Nexus acting as a proxy? Any suggestions on how to diagnose or fix this issue would be greatly appreciated. Thank you!
I’d suggest taking a look at the browse part of the user interface and see if repomd.xml is visible, and take a look at the Nexus logs (typically sonatype-work/nexus3/logs) to see if there are errors.
Aside from that some software (typically proxies, or anti-virus) can interfere with requests that can also lead to this sort of issue.
Thank you for the suggestions. I can confirm that repomd.xml is indeed visible in the repository browser. However, the download sometimes takes 1–3 minutes for a single file. Once the file is cached, everything works fine for a while, but whenever Nexus fetches new metadata again, the slow download issue reappears.
Additionally, I occasionally see errors with apt that look like a “mirror syn in progress?”. We’re planning to upgrade Nexus to the latest version soon and will check if the issue persists after that update. I didn’t see anything suspicious in the Nexus logs so far, but I’ll take a closer look next time the problem arises to gather more detailed information.
If you have any further ideas or recommendations in the meantime, I’d appreciate it. Thanks again for your help!
It happened again, and there are no logs in Nexus. I forgot to mention that I have a Nexus proxy pointing to another Nexus proxy, which in turn points to the official repositories. Could there be a problem with this setup?
On AlmaLinux it looks as though some packages are downloading very slowly:
Nexus needs to completely download and process each file before it serves it to the client. So when chaining Nexus instances, you’ll have the sum of the caching delay.
Proxy repositories have two settings one to configure the cache duration for metadata, and another for content (the rpms here). You could consider increasing they metadata timeout, that will delay finding new/updated packages but would reduce the frequency.
If the Nexus instance proxying the real repository has other users (e.g. its not just the second instance pulling data), you could consider having the second instance use a larger timeout for metadata to try to minimize the chained cache miss.
I’d generally suggest updating to recent versions of Nexus if you aren’t on a recent version as there have been performance improvements over time.
I have already increased the metadata cache duration on our central Nexus instance. However, at the end of our pipeline, we use an empty Nexus proxy to build an offline repository. This setup always pulls new packages and metadata, which can sometimes result in longer processing times.
We are considering upgrading Nexus to benefit from the performance improvements, but we would prefer to stay on the latest version that does not require a license for usage beyond 100,000 components. Do you happen to know if version 3.70.4-02 with OrientDB is still free of this licensing limitation? We’re also considering upgrading to 3.76.x with the H2 database if it remains within the free usage terms.
The issue comes from a chain of two Nexus proxy repositories. When a package or metadata file (like repomd.xml or a large .rpm) is not yet cached, the local Nexus waits while the central Nexus downloads the entire file from the upstream AlmaLinux repo before responding. This delay often causes curl error 28 or 502 errors, especially with large files or fresh metadata.
As a temporary workaround, I run a dummy download or yum makecache before provisioning, to warm up the cache and avoid timeouts.