Källan visar varför ett vanligt hastighetstest inte räcker för att diagnostisera långsamma installationer från Docker/App Store. Användarens ZimaBoard hade en fiberanslutning på 100 Mbps och MySpeed visade normal Internetkapacitet, men nedladdningen av programavbildningar gick ändå bara i KB/s och varje installation tog ungefär 20–30 minuter.
IceWhale misstänkte DNS, men bevisen är blandade. Användaren inaktiverade AdGuard Home/Nginx och ändrade DNS till Googles 8.8.8.8, men installationerna var fortfarande långsamma. Några dagar senare, efter uppdatering till 1.4.4.4-1, byte av DNS till Cloudflare 1.1.1.1 och omstart, återgick installationerna till normal hastighet. Eftersom flera variabler ändrades samtidigt bevisar källan inte att DNS ensamt orsakade eller löste problemet.
Ett snabbt hastighetstest bevisar inte att nedladdningar från Docker-register går snabbt
Ett webbaserat hastighetstest ansluter till en testserver i närheten. Installation av Docker-avbildningar kan däremot kontakta DNS-resolvers, registerändpunkter, autentiseringstjänster och CDN-värdar i olika regioner.
Normal surfning eller ett snabbt lokalt hastighetstest kan alltså förekomma samtidigt som hämtning av containeravbildningar går långsamt.
DNS var en rimlig hypotes, men inte bevisad av källan
Användaren hade AdGuard Home, Quad9 och Nginx i miljön. Giorgio föreslog att DNS-relaterade appar skulle inaktiveras och att en offentlig DNS-tjänst som 1.1.1.1 eller 8.8.8.8 skulle testas.
Det första kontrollerade testet – att inaktivera DNS-relaterade appar och byta till 8.8.8.8 – löste inte problemet med den långsamma installationen. Skriv därför inte att ”AdGuard orsakade det” eller att ”Google DNS löser det”.
Jämför docker pull på en annan maskin
IceWhales nästa diagnostikfråga var särskilt användbar: kör en Docker-hämtning av samma avbildning på en annan maskin som är ansluten till samma nätverk.
Om båda enheterna är långsamma bör du undersöka ISP-, register-, CDN- och DNS-routningen. Om bara ZimaOS är långsamt bör du fokusera på dess Docker-, nätverks- och systemstatus.
Kontrollera även lagringsutrymme och skrivprestanda
Installation av avbildningar skriver också data och packar upp lager. En nästan full systemdisk, långsam eller felande lagring eller tung samtidig I/O kan få en installation att verka nätverksbegränsad även när själva nedladdningen fungerar normalt.
I aktuella versioner av ZimaOS kan användare flytta Docker-avbildningar/AppData till större lagring och kontrollera användningen av applagringen.
Återställningen i källan innebar mer än ett DNS-byte
Det slutliga fungerande läget omfattade:
- ZimaOS uppdaterades till
1.4.4.4-1; - DNS ändrades till
1.1.1.1; - servern startades om.
Det gör resultatet verkligt, men grundorsaken är fortfarande okänd.
Aktuella ZimaOS är mycket nyare än 1.4.4
ZimaOS 1.7 introducerade App Store 2.0, och senare versioner förbättrade Docker-start, nätverkskonfiguration, YAML-kompatibilitet och appmigrering. Återskapa långsamma hämtningar på den aktuella stabila versionen innan du tillämpar kringlösningar från 2025.
Använd den aktuella baslinjen för ZimaOS 1.7.1.
Vanliga frågor om långsamma appinstallationer
Bevisade källan att Internetanslutningen var långsam?
Nej. Serverns normala hastighetstester var mycket snabbare än App Stores hämtningar av avbildningar i KB/s.
Löste bytet till 8.8.8.8 problemet?
Nej. Användaren uppgav uttryckligen att problemet kvarstod efter det testet.
Vad sammanföll slutligen med återställningen?
En uppdatering till 1.4.4.4-1, ett DNS-byte till 1.1.1.1 och en omstart; källan kan inte avgöra vilken ändring som var avgörande.
