เปรียบเทียบ ARM VPS กับ x86 VPS เลือกใช้อะไรดีกว่ากัน

สิ่งที่เปลี่ยนแปลงเมื่อย้ายไปใช้ ARM VPS

ARM VPS รัน Linux และ Nginx ตัวเดียวกับ x86 VPS และโดยปกติจะมีราคาต่อคอร์ที่ถูกกว่า ความเสี่ยงในการย้ายคือเรื่องความเข้ากันได้ โปรแกรมที่คอมไพล์มาสำหรับ x86-64 จะไม่สามารถรันบน arm64 ได้เลย ดังนั้นซอฟต์แวร์ทุกตัวใน stack ของคุณจะต้องมี build สำหรับ arm64 หรือเป็นซอฟต์แวร์ที่คุณสามารถคอมไพล์ใหม่เองได้

stack สมัยใหม่ส่วนใหญ่ผ่านการทดสอบนี้โดยไม่ต้องแก้ไขอะไร ความล้มเหลวจะกระจุกตัวอยู่ในสองจุด ได้แก่ container image ที่ถูกสร้างมาสำหรับสถาปัตยกรรมเดียวเท่านั้น และซอฟต์แวร์แบบปิด (closed source) ที่ไม่มีไฟล์ดาวน์โหลดสำหรับ arm64 คำสั่งด้านล่างนี้จะช่วยตอบคำถามทั้งสองข้อสำหรับ stack ของคุณก่อนที่คุณจะชำระเงินค่า instance หากคุณยังตัดสินใจไม่ได้ว่าต้องการเซิร์ฟเวอร์ประเภทใด ให้เริ่มต้นที่ VPS คืออะไรและแตกต่างจาก shared hosting อย่างไร

arm64, aarch64, amd64: ชื่อเหล่านี้หมายถึงอะไร

ให้รันคำสั่งเหล่านี้บนอินสแตนซ์ใดก็ตามก่อนดำเนินการอื่นใด

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

uname -m จะแสดงผล aarch64 บนเครื่อง ARM และแสดง x86_64 บนเครื่อง Intel หรือ AMD ส่วน dpkg --print-architecture จะแสดงผล arm64 และ amd64 สำหรับเครื่องทั้งสองประเภทดังกล่าว คำตอบทั้งสองแบบถูกต้อง เนื่องจาก Linux kernel และระบบจัดการแพ็กเกจของ Debian เลือกใช้ชื่อเรียกที่แตกต่างกันสำหรับชุดคำสั่งเดียวกัน ดังนั้น aarch64 และ arm64 จึงหมายถึงสิ่งเดียวกัน และ x86_64 และ amd64 ก็หมายถึงอีกสิ่งหนึ่ง Docker ใช้ชื่อเรียกตามแบบฉบับของ Debian ซึ่งเป็นเหตุผลว่าทำไมแพลตฟอร์มของอิมเมจจึงอ่านค่าได้เป็น linux/arm64

บน arm64 จะไม่มีบรรทัด model name ใน /proc/cpuinfo แต่คุณจะพบฟิลด์ Features แทน และการเข้ารหัสลับด้วยฮาร์ดแวร์จะปรากฏในนั้นเป็นแฟล็ก เช่น aes pmull sha1 sha2 ซึ่งเป็นส่วนขยายด้านการเข้ารหัสลับของ ARMv8 (ARMv8 Cryptographic Extensions) ที่ทำหน้าที่เช่นเดียวกับ AES-NI บนชิ้นส่วนของ Intel และ AMD นั่นคือการเร่งความเร็ว TLS (transport layer security) และการเข้ารหัสลับดิสก์ด้วยฮาร์ดแวร์ การตรวจสอบการเร่งความเร็วฮาร์ดแวร์ AES บน VPS ครอบคลุมวิธีการทดสอบบนสถาปัตยกรรมทั้งสองแบบ

เหตุใดคอนเทนเนอร์ถึงทำงานล้มเหลวเป็นอันดับแรก และลักษณะของข้อผิดพลาดเป็นอย่างไร

Docker image manifest ทุกรายการจะบันทึกสถาปัตยกรรมที่ถูกสร้างมาเพื่อรองรับไว้ หากคุณดึง (pull) image ที่มีเฉพาะ manifest แบบ amd64 มายังโฮสต์ที่เป็น arm64 การดึงข้อมูลจะสำเร็จ แต่ความล้มเหลวจะเกิดขึ้นเมื่อเริ่มกระบวนการ (process) ครั้งแรก:

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 คือการที่เคอร์เนลปฏิเสธการรันไฟล์ เนื่องจากส่วนหัว ELF (executable and linkable format) ระบุประเภทของเครื่องที่ CPU นี้ไม่รองรับ ไม่มีการตั้งค่าใดที่แก้ไขปัญหานี้ได้ เนื่องจากชุดคำสั่งดังกล่าวไม่มีอยู่ในตัวฮาร์ดแวร์

ตรวจสอบ manifest ก่อนที่คุณจะทำการ deploy:

docker buildx imagetools inspect nginx:1.27

ผลลัพธ์จะแสดงรายการ Platform: หนึ่งบรรทัดต่อหนึ่ง image ในรายการ manifest เช่น linux/amd64 และ linux/arm64 หากไม่มี linux/arm64 ปรากฏอยู่ tag นั้นจะไม่สามารถเริ่มทำงานบน ARM VPS ได้ docker manifest inspect --verbose nginx:1.27 แสดงข้อมูลเดียวกัน แต่ Docker ระบุว่า docker manifest เป็นคำสั่งทดลอง (experimental) ซึ่งพฤติกรรมอาจเปลี่ยนแปลงได้ในแต่ละรุ่น (release) ดังนั้นควรใช้ imagetools จะดีกว่า

สำหรับ image ที่คุณสร้างขึ้นเอง ให้สร้างทั้งสองสถาปัตยกรรมในคำสั่งเดียวและ push เป็น manifest list:

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

การสร้าง (build) สำหรับสถาปัตยกรรมอื่นบนโฮสต์เดียวจำเป็นต้องใช้ QEMU user mode emulation ที่ลงทะเบียนไว้กับตัวจัดการ binfmt_misc ของเคอร์เนล:

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

ใช้ emulation เพื่อการสร้างและทดสอบเท่านั้น ห้ามใช้เพื่อให้บริการรับส่งข้อมูล (traffic) เอกสารของ Docker เองระบุว่าการใช้ emulation ด้วย QEMU "อาจช้ากว่าการ build แบบ native มาก โดยเฉพาะงานที่เน้นการคำนวณ เช่น การคอมไพล์ และการบีบอัดหรือคลายข้อมูล" ดังนั้นบริการ x86 ที่รันผ่าน emulation บน instance แบบ ARM จะทำให้คุณสูญเสียความคุ้มค่าที่ทำให้คุณตัดสินใจย้ายมาในตอนแรก การตั้งค่าโฮสต์สำหรับกรณี native นั้นเหมือนกันในทั้งสองสถาปัตยกรรม: การรัน Docker บน VPS ได้ครอบคลุมเนื้อหานี้ไว้แล้ว และไฟล์ Compose ที่มีอยู่เดิมสามารถใช้งานได้ทันทีโดยไม่ต้องแก้ไข หากทุก image ในไฟล์นั้นมี manifest แบบ arm64 รองรับ

แพ็กเกจที่ฉันต้องการจะมีให้ใช้งานบน arm64 หรือไม่

Ubuntu และ Debian สร้าง archive เกือบทั้งหมดสำหรับสถาปัตยกรรม arm64 ดังนั้น apt install nginx postgresql redis-server จึงทำงานเหมือนกันในทั้งสองสถาปัตยกรรม ปัญหาจะเกิดขึ้นกับ repository ของบุคคลที่สาม

ให้สอบถาม apt โดยตรงบน instance แบบ ARM:

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

การที่ apt-cache policy รายงาน Candidate: (none) หมายความว่าไม่มี repository ที่เปิดใช้งานอยู่แห่งใดเผยแพร่ build ของแพ็กเกจนั้นสำหรับสถาปัตยกรรมนี้ ส่วน apt-get install -s จะเป็นการจำลองการติดตั้งโดยไม่มีการเขียนข้อมูลใดๆ และในกรณีเดียวกันนี้ มันจะจบลงด้วย E: Unable to locate package

จากนั้นให้อ่านผลลัพธ์ของ apt update แทนการเลื่อนผ่านไปเฉยๆ repository ของผู้จำหน่ายที่เป็น amd64 เท่านั้นจะระบุไว้ดังนี้:

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

repository ถูกกำหนดค่าไว้และเข้าถึงได้ แต่ไม่มีสิ่งที่เครื่องนี้สามารถติดตั้งได้ ให้ตรวจสอบรายการ source ด้วยเช่นกัน บรรทัดที่ถูกกำหนดด้วย [arch=amd64] จะถูกข้ามไปบน host แบบ arm64 ทำให้ดูเหมือนว่าแพ็กเกจนั้นหายไป ทั้งที่สาเหตุที่แท้จริงคือการกำหนด pin ไว้

เวิร์กโหลดประเภทใดที่ปลอดภัยและประเภทใดที่ต้องตรวจสอบก่อน

รันไทม์แบบ Interpreted และ bytecode ถูกออกแบบมาให้พกพาได้ (portable) โดยธรรมชาติ ทั้ง PHP, Python, Ruby และ Node.js ต่างมีแพ็กเกจสำหรับ arm64 ในดิสทริบิวชันหลัก ส่วน Go และ Rust สามารถทำ cross-compile ไปยัง arm64 ได้โดยการตั้งค่า target เพียงจุดเดียว ดังนั้น LEMP stack, Node API, Go binary ที่อยู่หลัง Nginx หรือฐานข้อมูล Postgres จึงเป็นงานปกติบน arm64

คอมไพเลอร์แบบ Just-in-time (JIT) จะสร้างรหัสเครื่อง (machine code) ในขณะที่โปรแกรมทำงาน จึงจำเป็นต้องมีตัวสร้างรหัสสำหรับสถาปัตยกรรมเป้าหมาย ซึ่งเวอร์ชันปัจจุบันรองรับทั้งหมด ไม่ว่าจะเป็น OpenJDK, .NET, V8 engine ที่อยู่ใน Node.js และ PyPy ต่างรองรับ arm64 บน Linux สิ่งที่เป็นอันตรายจริงๆ คือการใช้เวอร์ชันเก่าที่ถูกล็อกไว้ (pinned old versions) สคริปต์การติดตั้งที่ดึงรันไทม์เวอร์ชันเมื่อหลายปีก่อนมาใช้ ควรได้รับการตรวจสอบกับบันทึกประจำรุ่น (release notes) ของเวอร์ชันนั้นๆ ว่ารองรับ aarch64 หรือไม่ แทนที่จะทึกทักเอาเองว่าใช้งานได้

ไลบรารีที่มีการเขียน x86 assembly ด้วยมือ หรือใช้ SSE และ AVX intrinsics เป็นกรณีที่เงียบกว่า ส่วนใหญ่จะมีเส้นทางสำหรับ NEON (NEON คือชุดคำสั่งเวกเตอร์ของ ARM) หรือมีตัวสำรองที่เป็น C ล้วน ทำให้สามารถคอมไพล์และทำงานได้ ประสิทธิภาพอาจแตกต่างจากรุ่น x86 ได้ทั้งในทางที่ดีขึ้นหรือแย่ลง ควรวัดผลบนอินสแตนซ์ของคุณเองแทนการคาดเดาจากบทความ

ซอฟต์แวร์แบบปิด (closed source) คืออุปสรรคที่แท้จริง ตัวแทนตรวจสอบของเวนเดอร์ (monitoring agent), ไดรเวอร์ฐานข้อมูลที่มีลิขสิทธิ์, แผงควบคุมเชิงพาณิชย์ หรือ daemon ป้องกันไวรัส จะมาในรูปแบบ binary ที่คอมไพล์มาแล้ว และหากเวนเดอร์ไม่ได้เผยแพร่รุ่น arm64 คุณก็ไม่สามารถทำอะไรกับมันได้ cPanel และ WHM เป็นตัวอย่างที่ชัดเจนที่สุดในงานโฮสติ้ง: ความต้องการของระบบระบุไว้ว่าเป็น x86_64 และไม่ได้ระบุถึง ARM ดังนั้นเซิร์ฟเวอร์แผงควบคุมจึงต้องอยู่บน x86 ต่อไป (ตรวจสอบเมื่อเดือนสิงหาคม 2026 และควรตรวจสอบซ้ำที่หน้าความต้องการของระบบบนเว็บไซต์ของผู้ผลิต) หากนั่นเป็นสิ่งเดียวที่รั้งคุณไว้ ทางเลือกของ cPanel ที่น่าใช้งานบน VPS คือจุดเริ่มต้น และให้ตรวจสอบการรองรับสถาปัตยกรรมของแต่ละตัวด้วยวิธีเดียวกัน

เคอร์เนลและขนาดหน้าหน่วยความจำ (page size): จุดที่ ARM instance ยังคงมีความแตกต่าง

เซิร์ฟเวอร์ x86-64 แทบจะสามารถใช้งานแทนกันได้ทั้งหมด แต่เซิร์ฟเวอร์ ARM นั้นมีความหลากหลายมากกว่า และความแตกต่างเหล่านั้นอยู่ในระดับที่ต่ำกว่าแอปพลิเคชันของคุณ

ขนาดหน้าหน่วยความจำ (page size) เป็นปัจจัยหนึ่งที่ส่งผลกระทบต่อการใช้งานจริง เคอร์เนล arm64 ส่วนใหญ่ใช้ขนาด 4 KiB เช่นเดียวกับ x86-64 แต่บางส่วนใช้ขนาด 64 KiB โดย Red Hat Enterprise Linux 8 สำหรับ aarch64 ได้กำหนดให้เคอร์เนลขนาด 64 KiB เป็นค่าเริ่มต้น ส่วน RHEL 9 ได้เปลี่ยนค่าเริ่มต้นกลับมาเป็น 4 KiB โดยยังคงมีแพ็กเกจ kernel-64k แยกไว้สำหรับเวิร์กโหลดที่ต้องการขนาดที่ใหญ่กว่า ขนาดหน้าหน่วยความจำ 64 KiB จะเพิ่มการใช้หน่วยความจำขั้นต่ำสำหรับกระบวนการที่มีการแมปหน่วยความจำขนาดเล็กจำนวนมาก เนื่องจากหน่วยความจำส่วนที่เล็กที่สุดที่เคอร์เนลสามารถจัดสรรได้นั้นมีขนาดใหญ่กว่าเดิมถึง 16 เท่า ให้รันคำสั่ง getconf PAGESIZE บน instance เพื่ออ่านค่าจริงแทนการคาดเดา ขนาดหน้าหน่วยความจำไม่ใช่การตัดสินใจของเคอร์เนลเพียงอย่างเดียวที่ส่งผลถึงคุณ เนื่องจากเวอร์ชันที่ผู้ให้บริการของคุณจัดเตรียมมานั้นยังควบคุมวิธีการจัดตารางงานลงบนคอร์ประมวลผลด้วย และ การจัดตารางงานที่รับรู้แคช (cache aware scheduling) ซึ่งเพิ่มเข้ามาใน Linux 7.2 นั้นมีผลทั้งบน arm64 และ x86-64 เช่นเดียวกัน

มีความแตกต่างเล็กน้อยอื่นๆ ที่ควรทราบ บน arm64 ไม่มีแพ็กเกจ microcode ของ CPU สำหรับระบบปฏิบัติการ ดังนั้นการอัปเดตเฟิร์มแวร์จึงมาจากผู้ให้บริการของคุณ ไม่ใช่จาก apt เซิร์ฟเวอร์ ARM บูตผ่าน UEFI (unified extensible firmware interface) และอธิบายฮาร์ดแวร์ผ่าน ACPI (advanced configuration and power interface) ฟีเจอร์บางอย่างของ x86 ไม่มีฟีเจอร์ที่เทียบเท่าบน ARM รวมถึงการเข้ารหัสหน่วยความจำ AMD SEV และ GPU แบบ mediated อย่าง Intel GVT-g

แพลตฟอร์มเซิร์ฟเวอร์ ARM เติบโตเต็มที่แล้วหรือยัง?

ในด้านซอฟต์แวร์ คำตอบคือใช่ Debian, Ubuntu, Fedora และ RHEL ต่างก็ปล่อย build สำหรับ arm64 ที่มีคุณภาพระดับเฟิร์สคลาส และอิมเมจอย่างเป็นทางการบน Docker Hub ก็รองรับสถาปัตยกรรมแบบ multi-arch เป็นมาตรฐานอยู่แล้ว

หลักฐานที่ชัดเจนที่สุดเมื่อเร็วๆ นี้คือ Proxmox เมื่อวันที่ 5 สิงหาคม 2026 Proxmox ได้ประกาศเปิดตัว Proxmox Virtual Environment รุ่น arm64 ที่ได้รับการสนับสนุนอย่างเป็นทางการเป็นครั้งแรกในเวอร์ชัน 9.2 โดยใช้ package repository และวงจรการปล่อยซอฟต์แวร์ (release lifecycle) ร่วมกับรุ่น x86-64 ตัวซอฟต์แวร์สร้างขึ้นบน Debian 13.5 พร้อมด้วย Linux 7.0, QEMU 11.0, LXC 7.0 และ ZFS 2.4 ซึ่งการตั้งค่าและเครื่องมือต่างๆ นั้นเหมือนกับรุ่น x86-64 แทบทุกประการ ยกเว้นรายการเฉพาะทางสถาปัตยกรรมเพียงเล็กน้อยเท่านั้น

โปรดอ่านข้อควรระวังในประกาศฉบับเดียวกันนั้น เพราะจะแสดงให้เห็นว่าฮาร์ดแวร์เซิร์ฟเวอร์ ARM ที่ได้รับการสนับสนุนอย่างเป็นทางการนั้นยังมีจำกัดเพียงใด Proxmox ได้ตรวจสอบความถูกต้องของระบบ NVIDIA Grace และ NVIDIA Vera ตั้งแต่วันแรก หลังจากผ่านการทดสอบร่วมกับ NVIDIA และ Supermicro บนฮาร์ดแวร์ Grace Hopper ส่วนฮาร์ดแวร์ ARMv8-A และ ARMv9-A อื่นๆ ที่ใช้ UEFI จะได้รับการสนับสนุนแบบ best effort สำหรับคอมพิวเตอร์บอร์ดเดี่ยวที่ใช้เฉพาะ device tree อย่าง Raspberry Pi นั้นไม่ได้รับการสนับสนุน เกสต์ (guest) จะทำงานได้บนโหนดที่มีสถาปัตยกรรมเดียวกันเท่านั้น การทำ live migration จะทำได้เฉพาะระหว่างโหนดที่มีสถาปัตยกรรมเดียวกัน และคลัสเตอร์แบบผสมสถาปัตยกรรมยังไม่ได้รับการสนับสนุนอย่างเป็นทางการ

นั่นคือสถานะที่เป็นจริง ณ เดือนสิงหาคม 2026 การที่ผู้จำหน่าย hypervisor ปล่อยรุ่น arm64 โดยใช้รอบการพัฒนาเดียวกับ x86-64 ถือเป็นความก้าวหน้าที่แท้จริงของแพลตฟอร์มนี้ โดยรายการฮาร์ดแวร์ที่รองรับตั้งแต่วันแรกนั้นครอบคลุม CPU สองตระกูลหลัก

รายการตรวจสอบก่อนดำเนินการ

1. รัน uname -m บนอินสแตนซ์ทดลองและยืนยันว่าแสดงผลลัพธ์เป็น aarch64
2. รัน docker buildx imagetools inspect กับทุกอิมเมจในไฟล์ Compose ของคุณ และยืนยันว่ามีบรรทัด platform เป็น linux/arm64 สำหรับแต่ละรายการ
3. รัน apt update บนอินสแตนซ์ ARM และอ่านคำเตือน Skipping acquire ทุกรายการที่แสดงออกมา
4. เปิดหน้าดาวน์โหลดสำหรับเอเจนต์แบบปิดซอร์ส (closed source agent) ทุกตัวที่คุณใช้งาน และตรวจสอบหา build สำหรับ arm64 หรือ aarch64 ตามชื่อ
5. รัน getconf PAGESIZE และจดบันทึกคำตอบไว้ก่อนกำหนดขนาดหน่วยความจำ
6. รันการทดสอบประสิทธิภาพ (benchmark) ของคุณเองทั้งบนแผน ARM และแผน x86 ที่คุณกำลังเลือกเปรียบเทียบกัน

สิ่งที่บทความนี้ไม่ได้กล่าวอ้าง

เราจะไม่นำเสนออัตราส่วนราคาต่อประสิทธิภาพระหว่าง ARM กับ x86 ให้แก่คุณ เนื่องจากราคาต่อคอร์มีความแตกต่างกันไปตามผู้ให้บริการและแผนบริการ อีกทั้งตัวเลขที่วัดจากฮาร์ดแวร์ของผู้อื่นไม่สามารถนำมาคาดการณ์ผลลัพธ์บนฮาร์ดแวร์ของคุณได้ ขอให้คุณทำการวัดผลด้วยตนเอง คู่มือการทำ benchmarking บน VPS ของเรา ได้ครอบคลุมการใช้งาน sysbench และ fio ด้วยวิธีการที่คุณสามารถทำซ้ำได้ และ ต้นทุนที่แท้จริงของ VPS ได้ครอบคลุมด้านราคาสำหรับการเปรียบเทียบ ส่วนการจัดเก็บข้อมูลเป็นการตัดสินใจที่แยกต่างหากจากสถาปัตยกรรม CPU และ การเปรียบเทียบ NVMe กับ SATA SSD บน VPS ได้อธิบายในส่วนนั้นไว้แล้ว ให้คุณรันการทดสอบเดียวกันบนทั้งสองแผนบริการ โดยใช้ภาระงานจริงของคุณหากเป็นไปได้ แล้วให้ตัวเลขเหล่านั้นเป็นตัวตัดสินใจ

FAQ

Docker container ของฉันจะทำงานบน ARM VPS ได้หรือไม่?

มันจะทำงานได้หากทุก image ใน stack มีรายการ linux/arm64 อยู่ใน manifest ตรวจสอบแต่ละรายการด้วย docker buildx imagetools inspect <image> และมองหาบรรทัด Platform: linux/arm64 โดยปกติแล้ว image ทางการบน Docker Hub จะเป็นแบบ multi-arch แต่ image จากผู้ให้บริการรายย่อยหรือ image ที่คุณสร้างเองบนเครื่อง x86 มักจะไม่รองรับ สำหรับ image ของคุณเอง ให้สร้างใหม่ด้วย docker buildx build --platform linux/amd64,linux/arm64 ... --push เพื่อให้ tag เดียวรองรับทั้งสองสถาปัตยกรรม

exec format error หมายถึงอะไรบนเซิร์ฟเวอร์ ARM?

Kernel พยายามรัน binary ที่มี ELF header ระบุประเภทเครื่องที่ไม่ตรงกัน จึงปฏิเสธการทำงาน บน host แบบ arm64 กรณีนี้มักหมายถึง binary หรือ container image แบบ x86-64 Docker จะแสดงคำเตือนก่อนว่า platform ของ image ที่ร้องขอคือ linux/amd64 ไม่ตรงกับ platform ของ host ที่ตรวจพบคือ linux/arm64/v8 วิธีแก้ไขคือต้อง build สำหรับสถาปัตยกรรมที่ถูกต้อง ไม่มีการตั้งค่าใดที่ทำให้ binary แบบ x86-64 รันบน ARM ได้โดยตรง

arm64 เหมือนกับ aarch64 หรือไม่?

ใช่ ทั้งสองชื่อนี้ใช้เรียกชุดคำสั่ง ARM แบบ 64-bit เหมือนกัน Kernel จะรายงานเป็น aarch64 ผ่านทาง uname -m ในขณะที่การจัดการแพ็กเกจของ Debian และ Ubuntu รวมถึง platform string ของ Docker จะใช้ arm64 การแบ่งชื่อในลักษณะเดียวกันนี้เกิดขึ้นในฝั่งอื่นด้วย โดยที่ uname -m จะระบุเป็น x86_64 และการจัดการแพ็กเกจจะใช้ amd64 หากหน้าดาวน์โหลดเสนอเฉพาะไฟล์ aarch64 ไฟล์เหล่านั้นคือไฟล์ที่ถูกต้องสำหรับเครื่องที่ dpkg --print-architecture เรียกว่า arm64

ARM VPS เร็วกว่า x86 VPS หรือไม่?

คำถามนี้ไม่มีคำตอบตายตัว และอัตราส่วนใดๆ ที่คุณอ่านพบนั้นวัดมาจากฮาร์ดแวร์ที่ไม่ใช่ของคุณ ความเร็วขึ้นอยู่กับรุ่นของ CPU จำนวน core ที่ได้รับ การจัดการทรัพยากรของผู้ให้บริการ และประสิทธิภาพของ workload ของคุณในการใช้ vector instructions ให้ทำการ benchmark แผนการใช้งานทั้งสองแบบที่คุณกำลังตัดสินใจ โดยใช้ workload ของคุณเองหากเป็นไปได้ แล้วนำตัวเลขมาเปรียบเทียบกัน

ฉันควรตรวจสอบอะไรบ้างก่อนย้ายเซิร์ฟเวอร์ production ไปยัง arm64?

ให้ตรวจสอบ 4 รายการตามลำดับนี้ ยืนยันว่า container image ทุกตัวมี manifest สำหรับ arm64 ยืนยันว่า apt repository ของบุคคลที่สามทุกแห่งมีการเผยแพร่ binary-arm64 ยืนยันว่า agent แบบ closed source ทุกตัวมีไฟล์สำหรับดาวน์โหลดแบบ aarch64 จากนั้นให้รัน getconf PAGESIZE บน instance ปลายทาง เนื่องจาก kernel ที่ใช้ 64 KiB page จะเปลี่ยนการใช้หน่วยความจำของ process ที่มีการ mapping ขนาดเล็กจำนวนมาก หากมีสิ่งใดไม่ผ่านการตรวจสอบทั้ง 4 ข้อนี้ นั่นคือเหตุผลที่ควรคงเซิร์ฟเวอร์นั้นไว้บน x86 ต่อไป