VPS ARM vs x86: różnice w wydajności i kompatybilności

Co zmienia się po przejściu na VPS z architekturą ARM

VPS z architekturą ARM uruchamia ten sam system Linux i ten sam serwer Nginx co VPS x86, a zazwyczaj kosztuje mniej w przeliczeniu na rdzeń. Ryzyko związane z migracją dotyczy kompatybilności. Program skompilowany dla x86-64 nie uruchomi się na arm64, dlatego każdy element stosu technologicznego musi posiadać wersję dla arm64 lub umożliwiać samodzielną kompilację.

Większość nowoczesnych stosów przechodzi ten test bez dodatkowej pracy. Problemy pojawiają się w dwóch przypadkach: obrazy kontenerów przygotowane wyłącznie dla jednej architektury oraz oprogramowanie o zamkniętym kodzie źródłowym, dla którego nie udostępniono wersji arm64. Poniższe polecenia pozwalają sprawdzić oba te aspekty dla własnego stosu przed opłaceniem instancji. Jeśli nadal ustalasz, jakiego typu serwer jest potrzebny, zacznij od czym jest VPS i czym różni się od hostingu współdzielonego.

arm64, aarch64, amd64: co oznacza każda z nazw

Uruchom te polecenia na każdej instancji przed wykonaniem jakichkolwiek innych czynności.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m wyświetla aarch64 na maszynie ARM oraz x86_64 na maszynie z procesorem Intel lub AMD. dpkg --print-architecture wyświetla arm64 oraz amd64 dla tych samych dwóch typów maszyn. Obie odpowiedzi są poprawne. Jądro Linux oraz system pakietów Debian przyjęły różne nazwy dla tego samego zestawu instrukcji, dlatego aarch64 i arm64 oznaczają to samo, podobnie jak x86_64 i amd64. Docker używa nazw w stylu Debiana, dlatego platforma obrazu odczytywana jest jako linux/arm64.

W architekturze arm64 w pliku /proc/cpuinfo nie występuje linia model name. Zamiast niej znajduje się pole Features, w którym sprzętowe funkcje kryptograficzne widoczne są jako flagi, na przykład aes pmull sha1 sha2. Są to rozszerzenia kryptograficzne ARMv8 (ARMv8 Cryptographic Extensions), które pełnią tę samą funkcję co AES-NI w procesorach Intel i AMD: przyspieszają sprzętowo obsługę TLS (transport layer security) oraz szyfrowanie dysków. Artykuł Sprawdzanie sprzętowej akceleracji AES na VPS zawiera opis testu dla obu architektur.

Dlaczego kontenery ulegają awarii jako pierwsze i jak wyglądają błędy

Każdy manifest obrazu Docker zawiera informację o architekturze, dla której został zbudowany. Pobranie obrazu posiadającego wyłącznie manifest amd64 na hosta arm64 kończy się sukcesem. Awaria występuje dopiero przy próbie uruchomienia pierwszego procesu:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error oznacza, że jądro odmawia wykonania pliku, ponieważ nagłówek ELF (executable and linkable format) wskazuje typ architektury, której ten procesor nie obsługuje. Żadne ustawienie tego nie naprawi. Instrukcje nie istnieją w krzemie.

Przed wdrożeniem sprawdź manifest:

docker buildx imagetools inspect nginx:1.27

Dane wyjściowe wyświetlają jedną linię Platform: dla każdego obrazu w liście manifestów, na przykład linux/amd64 oraz linux/arm64. Jeśli linux/arm64 jest nieobecne, dany tag nie uruchomi się na serwerze VPS z architekturą ARM. docker manifest inspect --verbose nginx:1.27 pokazuje te same informacje, jednak dokumentacja Docker określa docker manifest jako polecenie eksperymentalne, którego działanie może ulec zmianie w kolejnych wydaniach, dlatego należy preferować imagetools.

W przypadku obrazów budowanych samodzielnie, należy zbudować obie architektury za pomocą jednego polecenia i wypchnąć listę manifestów:

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

Budowanie dla obcej architektury na pojedynczym hoście wymaga emulacji trybu użytkownika QEMU zarejestrowanej w obsłudze binfmt_misc jądra systemu:

docker run --privileged --rm tonistiigi/binfmt --install all

Emulacji należy używać do budowania i testowania. Nie należy jej używać do obsługi ruchu sieciowego. Dokumentacja Docker stwierdza, że emulacja za pomocą QEMU "może być znacznie wolniejsza niż natywne kompilacje, szczególnie w przypadku zadań wymagających dużej mocy obliczeniowej, takich jak kompilacja, kompresja lub dekompresja", więc emulowana usługa x86 na instancji ARM niweluje oszczędności, które skłoniły do migracji. Konfiguracja hosta dla przypadku natywnego jest identyczna dla obu architektur: uruchamianie Docker na VPS opisuje ten proces, a istniejący plik Compose działa bez zmian, gdy każdy zawarty w nim obraz posiada manifest arm64.

Czy potrzebne pakiety będą dostępne dla arm64?

Ubuntu oraz Debian kompilują niemal całe archiwum dla architektury arm64, więc apt install nginx postgresql redis-server zachowuje się identycznie na obu architekturach. Braki występują głównie w zewnętrznych repozytoriach.

Należy zapytać bezpośrednio narzędzie apt na instancji ARM:

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy zgłaszające Candidate: (none) oznacza, że żadne aktywne repozytorium nie publikuje wersji tego pakietu dla tej architektury. apt-get install -s symuluje instalację bez wprowadzania zmian, a w takim przypadku kończy się komunikatem E: Unable to locate package.

Następnie należy przeczytać dane wyjściowe apt update zamiast je przewijać. Repozytorium dostawcy ograniczone do amd64 informuje o tym wprost:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Repozytorium jest skonfigurowane i osiągalne, ale nie zawiera niczego, co można zainstalować na tej maszynie. Należy również sprawdzić sam wpis źródłowy. Linia z przypięciem [arch=amd64] jest pomijana na hoście arm64, przez co pakiet wydaje się niedostępny, podczas gdy rzeczywistą przyczyną jest właśnie to przypięcie.

Które obciążenia są bezpieczne, a które wymagają wcześniejszej weryfikacji

Środowiska uruchomieniowe oparte na interpretacji kodu oraz bajtkodzie są z założenia przenośne. PHP, Python, Ruby oraz Node.js posiadają pakiety arm64 w głównych dystrybucjach. Języki Go oraz Rust umożliwiają kompilację skrośną dla arm64 poprzez ustawienie jednego celu. Stos LEMP, API w Node, binaria Go za Nginx czy baza danych Postgres to standardowe obciążenia na architekturze arm64.

Kompilator JIT (Just-In-Time) generuje kod maszynowy w trakcie działania programu, dlatego wymaga generatora kodu dla docelowej architektury. Obecne wersje posiadają takie wsparcie: OpenJDK, .NET, silnik V8 wewnątrz Node.js oraz PyPy obsługują arm64 w systemie Linux. Prawdziwym zagrożeniem są przypięte do konkretnych wersji starsze wydania. Skrypt wdrożeniowy instalujący środowisko uruchomieniowe sprzed kilku lat powinien zostać zweryfikowany pod kątem informacji o wydaniu w zakresie wsparcia aarch64, zamiast zakładać, że zadziała poprawnie.

Biblioteki zawierające ręcznie pisany kod asemblera x86 lub instrukcje wbudowane SSE i AVX stanowią mniej oczywisty przypadek. Większość z nich posiada ścieżkę NEON (NEON to zestaw instrukcji wektorowych ARM) lub standardowy zamiennik w języku C, dzięki czemu kompilują się i działają. Wydajność może różnić się od kompilacji x86 w obie strony. Należy zmierzyć ją na własnej instancji, zamiast przewidywać wyniki na podstawie artykułów.

Oprogramowanie o zamkniętym kodzie źródłowym stanowi rzeczywistą przeszkodę. Agent monitorujący dostawcy, licencjonowany sterownik bazy danych, komercyjny panel sterowania czy demon antywirusowy są dostarczane jako skompilowane pliki binarne. Jeśli dostawca nie opublikował wersji arm64, nie ma możliwości obejścia tego ograniczenia. cPanel oraz WHM to najbardziej wyrazisty przykład w hostingu: wymagania systemowe wskazują na x86_64 i nie wymieniają ARM, dlatego serwer z panelem sterowania musi pozostać na x86 (stan na sierpień 2026, warto ponownie sprawdzić stronę wymagań dostawcy). Jeśli jest to jedyny czynnik powstrzymujący przed migracją, alternatywy dla cPanel warte uruchomienia na VPS to właściwy punkt wyjścia; w przypadku każdej z nich należy w ten sam sposób sprawdzić wsparcie dla architektury.

Jądra systemu i rozmiar strony: w czym instancje ARM nadal się różnią

Serwery x86-64 są niemal zamienne. Serwery ARM są mniej jednolite, a różnice znajdują się poniżej poziomu aplikacji.

Rozmiar strony pamięci jest parametrem, który wpływa na środowisko produkcyjne. Większość jąder arm64 używa stron 4 KiB, podobnie jak x86-64. Niektóre używają 64 KiB. Red Hat Enterprise Linux 8 dla aarch64 domyślnie dostarczał jądro ze stronami 64 KiB, natomiast RHEL 9 powrócił do domyślnych 4 KiB, zachowując oddzielny pakiet kernel-64k dla obciążeń wymagających większego rozmiaru. Rozmiar strony 64 KiB podnosi minimalne zużycie pamięci przez proces z wieloma małymi mapowaniami, ponieważ najmniejszy fragment, jaki jądro może przydzielić, jest szesnastokrotnie większy. Uruchom getconf PAGESIZE na instancji i odczytaj wartość, zamiast zakładać ją z góry. Rozmiar strony nie jest jedyną decyzją jądra, która ma znaczenie, ponieważ wersja dostarczana przez dostawcę określa również sposób szeregowania zadań na rdzeniach, a mechanizm szeregowania uwzględniający pamięć podręczną dodany w Linux 7.2 trafia zarówno na arm64, jak i x86-64.

Warto znać kilka mniejszych różnic. Na arm64 nie ma pakietów mikrokodu procesora dla systemu operacyjnego, więc aktualizacje oprogramowania układowego pochodzą od dostawcy, a nie z apt. Serwery ARM uruchamiają się poprzez UEFI (unified extensible firmware interface) i opisują swój sprzęt za pomocą ACPI (advanced configuration and power interface). Niektóre funkcje x86 nie mają odpowiedników w ARM, w tym szyfrowanie pamięci AMD SEV oraz wirtualizacja GPU Intel GVT-g.

Czy platforma serwerowa ARM osiągnęła dojrzałość?

Pod względem oprogramowania, tak. Debian, Ubuntu, Fedora oraz RHEL oferują pełnowartościowe kompilacje arm64, a oficjalne obrazy w Docker Hub są standardowo wieloarchitektoniczne.

Najwyraźniejszym dowodem z ostatniego okresu jest Proxmox. W dniu 5 sierpnia 2026 r. Proxmox ogłosił pierwszą oficjalnie wspieraną edycję arm64 dla Proxmox Virtual Environment, wersję 9.2, współdzielącą repozytoria pakietów oraz cykl wydawniczy z edycją x86-64. System bazuje na Debian 13.5 z jądrem Linux 7.0, QEMU 11.0, LXC 7.0 oraz ZFS 2.4, a konfiguracja i narzędzia są identyczne jak w wersji x86-64, z wyjątkiem niewielkiego zestawu elementów specyficznych dla architektury.

Należy zapoznać się z zastrzeżeniami zawartymi w tym samym ogłoszeniu, ponieważ pokazują one, jak wąski jest nadal zakres oficjalnie wspieranego sprzętu serwerowego ARM. Proxmox zweryfikował systemy NVIDIA Grace oraz NVIDIA Vera w dniu premiery, po wspólnych testach z NVIDIA i Supermicro na sprzęcie Grace Hopper. Pozostały sprzęt ARMv8-A i ARMv9-A oparty na UEFI jest wspierany w ramach najlepszych starań (best effort). Komputery jednopłytkowe korzystające wyłącznie z Device Tree, takie jak Raspberry Pi, nie są wspierane. Gość uruchamia się tylko na węźle o tej samej architekturze, migracja na żywo działa wyłącznie między węzłami o tej samej architekturze, a klastry o mieszanej architekturze nie są oficjalnie wspierane.

Tak przedstawia się rzetelny stan rzeczy na sierpień 2026 r. Dostawca hypervisora wydający arm64 w tym samym cyklu życia co x86-64 to realny postęp dla tej platformy. Lista sprzętu wspieranego w dniu premiery obejmuje dwie rodziny procesorów.

Lista kontrolna przed zatwierdzeniem zmian

1. Uruchom uname -m na instancji testowej i potwierdź, że wyświetla aarch64.
2. Uruchom docker buildx imagetools inspect dla każdego obrazu w pliku Compose i potwierdź obecność linii linux/arm64 dla każdej platformy.
3. Uruchom apt update na instancji ARM i przeczytaj każde ostrzeżenie Skipping acquire, które zostanie wyświetlone.
4. Otwórz stronę pobierania dla każdego agenta o zamkniętym kodzie źródłowym, od którego zależy system, i wyszukaj kompilację arm64 lub aarch64 po nazwie.
5. Uruchom getconf PAGESIZE i zanotuj wynik przed określeniem zapotrzebowania na pamięć.
6. Przeprowadź własny test wydajnościowy zarówno na planie ARM, jak i na planie x86, pomiędzy którymi dokonujesz wyboru.

Czego ten wpis nie zakłada

Nie przedstawiamy stosunku ceny do wydajności dla architektury ARM w porównaniu z x86. Ceny za rdzeń różnią się w zależności od dostawcy i planu, a wyniki pomiarów na cudzym sprzęcie nie przewidzą wydajności Twojego rozwiązania. Należy przeprowadzić własne pomiary. Nasz przewodnik po benchmarkach VPS opisuje narzędzia sysbench oraz fio wraz z metodologią, którą można powtórzyć, a rzeczywiste koszty VPS omawiają kwestie cenowe w tym porównaniu. Pamięć masowa to decyzja niezależna od architektury procesora, a kwestię tę porusza artykuł porównanie NVMe z SATA SSD na VPS. Uruchom te same testy na obu planach, w miarę możliwości z własnym obciążeniem, i pozwól, aby to liczby podjęły decyzję.

FAQ

Czy moje kontenery Docker będą działać na VPS z architekturą ARM?

Będą działać, jeśli każdy obraz w stosie posiada wpis linux/arm64 w swoim manifeście. Sprawdź każdy z nich za pomocą docker buildx imagetools inspect <image> i poszukaj linii Platform: linux/arm64. Oficjalne obrazy w Docker Hub są zazwyczaj wieloarchitektoniczne. Obrazy od mniejszych dostawców oraz obrazy zbudowane samodzielnie na maszynie x86 często takie nie są. W przypadku własnych obrazów należy przeprowadzić ponowną budowę za pomocą docker buildx build --platform linux/amd64,linux/arm64 ... --push, aby jeden tag obsługiwał obie architektury.

Co oznacza exec format error na serwerze ARM?

Jądro systemu próbowało wykonać plik binarny, którego nagłówek ELF wskazuje na inny typ architektury, i odmówiło jego uruchomienia. Na hoście arm64 oznacza to niemal zawsze plik binarny lub obraz kontenera w architekturze x86-64. Docker wyświetla najpierw ostrzeżenie, informując, że żądana platforma obrazu linux/amd64 nie pasuje do wykrytej platformy hosta linux/arm64/v8. Rozwiązaniem jest zbudowanie obrazu dla właściwej architektury. Żadna zmiana konfiguracji nie sprawi, że plik binarny x86-64 zadziała natywnie na ARM.

Czy arm64 to to samo co aarch64?

Tak. Są to dwie nazwy dla 64-bitowego zestawu instrukcji ARM. Jądro systemu zgłasza aarch64 poprzez uname -m, podczas gdy pakiety w systemach Debian i Ubuntu oraz ciągi platform w Docker używają arm64. Ten sam podział występuje po drugiej stronie, gdzie uname -m podaje x86_64, a nazewnictwo pakietów amd64. Jeśli strona pobierania oferuje tylko pliki aarch64, są to właściwe pliki dla maszyny, którą dpkg --print-architecture określa jako arm64.

Czy VPS z ARM jest szybszy niż VPS z x86?

Na to pytanie nie ma ogólnej odpowiedzi, a każdy pojedynczy wskaźnik wydajności został zmierzony na sprzęcie innym niż Twój. Szybkość zależy od konkretnego modelu procesora, liczby przydzielonych rdzeni, sposobu zarządzania współdzieleniem zasobów przez dostawcę oraz od tego, jak dobrze Twoje obciążenie wykorzystuje instrukcje wektorowe. Przeprowadź testy porównawcze obu planów, między którymi wybierasz, najlepiej przy użyciu własnego obciążenia, i porównaj uzyskane wyniki.

Co należy sprawdzić przed przeniesieniem serwera produkcyjnego na arm64?

Cztery kroki, w tej kolejności. Potwierdź, że każdy obraz kontenera posiada manifest arm64. Potwierdź, że każde zewnętrzne repozytorium apt publikuje pakiety binary-arm64. Potwierdź, że każdy agent o zamkniętym kodzie źródłowym posiada wersję dla aarch64. Następnie uruchom getconf PAGESIZE na docelowej instancji, ponieważ jądro z rozmiarem strony 64 KiB zmienia sposób wykorzystania pamięci przez procesy z wieloma małymi mapowaniami. Każdy element, który nie przejdzie pomyślnie jednego z tych czterech testów, jest powodem, aby utrzymać dany serwer na architekturze x86.