Perbezaan VPS ARM vs x86: Adakah Stack Anda Sesuai?

Perubahan apabila beralih ke VPS ARM

VPS ARM menjalankan Linux dan Nginx yang sama seperti VPS x86, dan biasanya kos per teras adalah lebih rendah. Risiko dalam penukaran ini ialah keserasian. Program yang dikompilasi untuk x86-64 tidak boleh dijalankan pada arm64 sama sekali, jadi setiap perisian dalam tindanan (stack) anda perlu menyediakan binaan arm64 atau merupakan sesuatu yang boleh anda bina semula.

Kebanyakan tindanan moden melepasi ujian ini tanpa sebarang kerja tambahan. Kegagalan biasanya tertumpu pada dua perkara: imej kontena yang hanya dibina untuk satu seni bina, dan perisian sumber tertutup yang tidak mempunyai muat turun arm64. Perintah di bawah menjawab kedua-dua persoalan bagi tindanan anda sendiri sebelum anda membayar untuk sebuah instans. Jika anda masih menentukan jenis pelayan yang diperlukan, mulakan dengan apa itu VPS dan perbezaannya dengan pengehosan kongsi.

arm64, aarch64, amd64: nama mana bermaksud apa

Jalankan arahan ini pada mana-mana instans sebelum melakukan perkara lain.

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

uname -m mencetak aarch64 pada mesin ARM dan x86_64 pada mesin Intel atau AMD. dpkg --print-architecture mencetak arm64 dan amd64 untuk kedua-dua mesin tersebut. Kedua-dua jawapan adalah betul. Kernel Linux dan sistem pakej Debian memilih nama yang berbeza untuk set arahan yang sama, jadi aarch64 dan arm64 membawa satu maksud, manakala x86_64 dan amd64 membawa maksud yang satu lagi. Docker menggunakan nama gaya Debian, itulah sebabnya platform imej membaca linux/arm64.

Pada arm64, tiada baris model name dalam /proc/cpuinfo. Anda akan mendapat medan Features sebaliknya, dan kriptografi perkakasan muncul di sana sebagai flag seperti aes pmull sha1 sha2. Itu adalah ARMv8 Cryptographic Extensions, dan ia melakukan tugas yang dilakukan oleh AES-NI pada komponen Intel dan AMD: ia menjadikan TLS (transport layer security) dan penyulitan cakera pantas di peringkat perkakasan. Memeriksa pecutan perkakasan AES pada VPS merangkumi ujian pada kedua-dua seni bina tersebut.

Mengapa kontena gagal terlebih dahulu, dan rupa bentuk ralat tersebut

Setiap manifest imej Docker merekodkan seni bina yang ia dibina untuknya. Tarik imej yang hanya mempunyai manifest amd64 ke hos arm64 dan proses penarikan tersebut berjaya. Kegagalan berlaku pada permulaan proses pertama:

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 ialah kernel yang enggan menjalankan fail tersebut, kerana pengepala ELF (executable and linkable format) menamakan jenis mesin yang tidak dilaksanakan oleh CPU ini. Tiada tetapan yang dapat membaikinya. Arahan tersebut tidak wujud dalam silikon.

Semak manifest sebelum anda melakukan deployment:

docker buildx imagetools inspect nginx:1.27

Output tersebut menyenaraikan satu baris Platform: bagi setiap imej dalam senarai manifest, seperti linux/amd64 dan linux/arm64. Jika linux/arm64 tiada, tag tersebut tidak akan bermula pada VPS ARM. docker manifest inspect --verbose nginx:1.27 menunjukkan maklumat yang sama, tetapi Docker mendokumentasikan docker manifest sebagai arahan eksperimental yang kelakuannya boleh berubah antara release, jadi lebih baik gunakan imagetools.

Bagi imej yang anda bina sendiri, bina kedua-dua seni bina dalam satu arahan dan tolak (push) senarai manifest:

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

Membina untuk seni bina asing pada satu hos memerlukan emulasi mod pengguna QEMU yang didaftarkan dengan pengendali binfmt_misc kernel:

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

Gunakan emulasi untuk membina dan menguji. Jangan gunakannya untuk melayan trafik. Dokumentasi Docker sendiri menyatakan bahawa emulasi dengan QEMU "boleh menjadi jauh lebih perlahan daripada binaan natif, terutamanya untuk tugasan berat pengkomputeran seperti kompilasi dan pemampatan atau penyahmampatan", jadi servis x86 yang diemulasi pada instans ARM akan menghapuskan penjimatan yang menyebabkan anda berpindah. Persediaan hos untuk kes natif adalah sama pada kedua-dua seni bina: menjalankan Docker pada VPS meliputinya, dan fail Compose sedia ada berfungsi tanpa perubahan sebaik sahaja setiap imej di dalamnya mempunyai manifest arm64.

Adakah pakej yang saya perlukan tersedia pada arm64?

Ubuntu dan Debian membina hampir keseluruhan arkib untuk arm64, jadi apt install nginx postgresql redis-server berkelakuan sama pada kedua-dua seni bina tersebut. Jurang ketersediaan biasanya berlaku pada repositori pihak ketiga.

Tanya apt secara terus pada instans ARM:

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

apt-cache policy yang melaporkan Candidate: (none) bermaksud tiada repositori yang didayakan menerbitkan binaan pakej tersebut untuk seni bina ini. apt-get install -s mensimulasikan pemasangan dan tidak menulis apa-apa, dan dalam kes yang sama ia berakhir dengan E: Unable to locate package.

Kemudian baca output apt update dan jangan sekadar menatal melewatinya. Repositori vendor yang hanya menyokong amd64 akan menyatakan perkara tersebut:

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

Repositori tersebut dikonfigurasikan dan boleh dicapai, namun ia tidak mengandungi apa-apa yang boleh dipasang oleh mesin ini. Periksa juga entri sumber itu sendiri. Baris yang disemat dengan [arch=amd64] akan dilangkau pada hos arm64, jadi pakej tersebut kelihatan tiada sedangkan punca sebenar adalah penyematan (pin) tersebut.

Beban kerja yang selamat dan yang perlu diperiksa terlebih dahulu

Runtime yang ditafsir (interpreted) dan berasaskan bytecode direka bentuk untuk mudah alih. PHP, Python, Ruby dan Node.js semuanya mempunyai pakej arm64 dalam pengedaran utama. Go dan Rust boleh disilang-kompil (cross-compile) ke arm64 dengan menetapkan satu sasaran. Stak LEMP, API Node, binari Go di sebalik Nginx atau pangkalan data Postgres adalah kerja biasa pada arm64.

Pengkompil just-in-time (JIT) menghasilkan kod mesin semasa program berjalan, jadi ia memerlukan penjana kod untuk seni bina sasaran. Versi semasa mempunyai penjana kod tersebut: OpenJDK, .NET, enjin V8 di dalam Node.js dan PyPy semuanya menyokong arm64 pada Linux. Versi lama yang dipinkan (pinned) adalah risiko sebenar. Skrip penempatan (deploy script) yang memasang keluaran runtime dari beberapa tahun lalu harus disemak dengan nota keluaran tersebut untuk sokongan aarch64, bukannya terus menganggap ia akan berfungsi.

Pustaka yang membawa kod pemasangan (assembly) x86 yang ditulis tangan, atau intrinsik SSE dan AVX, adalah kes yang lebih senyap. Kebanyakannya juga mempunyai laluan NEON (NEON ialah set arahan vektor ARM) atau sandaran C biasa, jadi ia boleh dikompil dan dijalankan. Prestasi mungkin berbeza daripada binaan x86 dalam mana-mana arah. Ukur prestasi itu pada instans anda sendiri daripada meramalkannya berdasarkan artikel.

Perisian sumber tertutup adalah penghalang sebenar. Ejen pemantauan vendor, pemacu pangkalan data berlesen, panel kawalan komersial atau daemon anti-virus tiba sebagai binari yang telah dikompil, dan apabila vendor tidak menerbitkan binaan arm64, tiada apa yang boleh anda lakukan mengenainya. cPanel dan WHM adalah kes paling jelas dalam pengehosan: keperluan sistemnya menamakan x86_64 dan tidak menyenaraikan ARM, jadi pelayan panel kawalan kekal pada x86 (disemak Ogos 2026, dan wajar dibaca semula pada halaman keperluan vendor itu sendiri). Jika itu satu-satunya perkara yang menghalang anda, alternatif cPanel yang berbaloi untuk dijalankan pada VPS adalah tempat untuk bermula, dan semak sokongan seni bina setiap satu dengan cara yang sama.

Kernel dan saiz halaman: di mana instans ARM masih berbeza

Pelayan x86-64 hampir boleh ditukar ganti. Pelayan ARM kurang seragam, dan perbezaannya terletak di bawah aplikasi anda.

Saiz halaman adalah perkara yang memberi kesan kepada pengeluaran. Kebanyakan kernel arm64 menggunakan halaman 4 KiB, sama seperti x86-64. Sesetengahnya menggunakan 64 KiB. Red Hat Enterprise Linux 8 untuk aarch64 menghantar kernel dengan saiz halaman 64 KiB secara lalai, dan RHEL 9 menukar lalai tersebut kembali kepada 4 KiB sambil mengekalkan pakej kernel-64k yang berasingan untuk beban kerja yang memerlukan saiz lebih besar. Saiz halaman 64 KiB meningkatkan penggunaan memori minimum bagi proses yang mempunyai banyak pemetaan kecil, kerana ketulan terkecil yang boleh diberikan oleh kernel adalah enam belas kali ganda lebih besar. Jalankan getconf PAGESIZE pada instans tersebut dan baca nombornya daripada membuat andaian.

Terdapat beberapa perbezaan kecil lain yang perlu diketahui. Tiada pakej mikrokod CPU sistem pengendalian pada arm64, jadi kemas kini perisian tegar datang daripada pembekal anda dan bukan daripada apt. Pelayan ARM but melalui UEFI (unified extensible firmware interface) dan menerangkan perkakasan mereka melalui ACPI (advanced configuration and power interface). Sesetengah ciri x86 tidak mempunyai padanan langsung pada ARM, termasuk penyulitan memori AMD SEV dan GPU berperantara Intel GVT-g.

Adakah platform pelayan ARM sudah matang?

Dari segi perisian, ya. Debian, Ubuntu, Fedora dan RHEL semuanya mengeluarkan binaan arm64 kelas pertama, dan imej rasmi di Docker Hub secara lazimnya adalah berbilang seni bina (multi-arch).

Bukti terkini yang paling jelas ialah Proxmox. Pada 5 Ogos 2026, Proxmox mengumumkan edisi arm64 yang disokong secara rasmi buat pertama kalinya untuk Proxmox Virtual Environment, versi 9.2, yang berkongsi repositori pakej dan kitaran hayat keluaran dengan edisi x86-64. Ia dibina di atas Debian 13.5 dengan Linux 7.0, QEMU 11.0, LXC 7.0 dan ZFS 2.4, manakala konfigurasi dan peralatan yang digunakan adalah sama dengan x86-64 kecuali bagi sebilangan kecil item khusus seni bina.

Baca amaran dalam pengumuman yang sama, kerana ia menunjukkan betapa terhadnya perkakasan pelayan ARM yang disokong secara rasmi pada masa ini. Proxmox mengesahkan sistem NVIDIA Grace dan NVIDIA Vera pada hari pertama, selepas ujian bersama dengan NVIDIA dan Supermicro pada perkakasan Grace Hopper. Perkakasan ARMv8-A dan ARMv9-A berasaskan UEFI yang lain mendapat sokongan usaha terbaik (best effort). Komputer papan tunggal (single board computer) yang hanya menggunakan device tree seperti Raspberry Pi tidak disokong. Tetamu (guest) hanya boleh berjalan pada nod dengan seni bina yang sama, migrasi langsung (live migration) hanya berfungsi antara nod dengan seni bina yang sama, dan kluster seni bina campuran tidak disokong secara rasmi.

Itulah kedudukan sebenar setakat Ogos 2026. Seorang vendor hypervisor yang mengeluarkan arm64 pada kitaran hayat yang sama dengan x86-64 merupakan kemajuan sebenar bagi platform tersebut. Senarai perkakasan yang disokong pada hari pertama hanyalah dua keluarga CPU.

Senarai semak sebelum anda melakukan commit

1. Jalankan uname -m pada instans percubaan dan pastikan ia mencetak aarch64.
2. Jalankan docker buildx imagetools inspect pada setiap imej dalam fail Compose anda dan pastikan terdapat baris platform linux/arm64 untuk setiap satu.
3. Jalankan apt update pada instans ARM dan baca setiap amaran Skipping acquire yang dicetaknya.
4. Buka halaman muat turun bagi setiap ejen sumber tertutup yang anda gunakan dan cari binaan arm64 atau aarch64 mengikut nama.
5. Jalankan getconf PAGESIZE dan catatkan jawapannya sebelum anda menetapkan saiz memori.
6. Jalankan penanda aras anda sendiri pada pelan ARM dan pelan x86 yang anda pilih.

Perkara yang tidak didakwa dalam catatan ini

Kami tidak akan memberikan nisbah harga kepada prestasi bagi ARM berbanding x86. Harga setiap teras berbeza mengikut penyedia dan pelan, dan angka yang diukur pada perkakasan orang lain tidak dapat meramalkan hasil bagi perkakasan anda. Sebaliknya, lakukan pengukuran sendiri. Panduan kami untuk penanda aras VPS merangkumi sysbench dan fio dengan kaedah yang boleh anda ulangi, dan kos sebenar sebuah VPS merangkumi aspek harga dalam perbandingan tersebut. Storan merupakan keputusan yang berasingan daripada seni bina CPU, dan perbandingan NVMe dengan SATA SSD pada VPS membincangkan bahagian tersebut. Jalankan ujian yang sama pada kedua-dua pelan, gunakan beban kerja anda sendiri jika boleh, dan biarkan angka anda yang menentukan keputusan.

FAQ

Adakah kontena Docker saya akan berjalan pada VPS ARM?

Kontena tersebut akan berjalan jika setiap imej dalam tindanan (stack) mempunyai entri linux/arm64 dalam manifesnya. Semak setiap satu dengan docker buildx imagetools inspect <image> dan cari baris Platform: linux/arm64. Imej rasmi di Docker Hub biasanya menyokong berbilang seni bina (multi-arch). Imej daripada vendor kecil, dan imej yang anda bina sendiri pada mesin x86, selalunya tidak menyokongnya. Bagi imej anda sendiri, bina semula dengan docker buildx build --platform linux/amd64,linux/arm64 ... --push supaya satu tag boleh digunakan untuk kedua-dua seni bina.

Apakah maksud exec format error pada pelayan ARM?

Kernel cuba melaksanakan binari yang pengepala ELF-nya menamakan jenis mesin yang berbeza, lalu ia menolak. Pada hos arm64, ini hampir selalu bermaksud binari atau imej kontena x86-64. Docker akan mencetak amaran terlebih dahulu, menyatakan bahawa platform imej yang diminta linux/amd64 tidak sepadan dengan platform hos yang dikesan linux/arm64/v8. Penyelesaiannya adalah dengan membina imej untuk seni bina yang betul. Tiada perubahan konfigurasi yang boleh membuatkan binari x86-64 berjalan secara natif pada ARM.

Adakah arm64 sama dengan aarch64?

Ya. Kedua-duanya adalah nama untuk set arahan ARM 64-bit. Kernel melaporkan aarch64 melalui uname -m, manakala pembungkusan Debian dan Ubuntu, serta rentetan platform Docker, menggunakan arm64. Perbezaan yang sama wujud pada sisi lain, di mana uname -m menyatakan x86_64 dan pembungkusan menyatakan amd64. Jika halaman muat turun hanya menawarkan fail aarch64, itu adalah fail yang betul untuk mesin yang dipanggil arm64 oleh dpkg --print-architecture.

Adakah VPS ARM lebih pantas daripada VPS x86?

Soalan itu tidak mempunyai jawapan umum, dan sebarang nisbah tunggal yang anda baca diukur pada perkakasan yang bukan milik anda. Kelajuan bergantung pada model CPU tertentu, bilangan teras yang diberikan kepada anda, cara penyedia mengendalikan pertikaian antara penyewa, dan sejauh mana beban kerja anda menggunakan arahan vektor. Lakukan penanda aras (benchmark) pada dua pelan yang anda sedang pilih, gunakan beban kerja anda sendiri jika boleh, dan bandingkan angka-angka tersebut.

Apakah yang perlu saya semak sebelum memindahkan pelayan pengeluaran (production) ke arm64?

Empat semakan, mengikut urutan ini. Sahkan setiap imej kontena mempunyai manifes arm64. Sahkan setiap repositori apt pihak ketiga menerbitkan binary-arm64. Sahkan setiap ejen sumber tertutup mempunyai muat turun aarch64. Kemudian jalankan getconf PAGESIZE pada instans sasaran, kerana kernel dengan saiz halaman 64 KiB mengubah jejak memori bagi proses yang mempunyai banyak pemetaan kecil. Apa-apa sahaja yang gagal dalam salah satu daripada empat semakan tersebut adalah sebab untuk mengekalkan pelayan tersebut pada x86.