ARM VPS กับ x86 ต่างกันอย่างไร เลือกแบบไหนคุ้มกว่า

สิ่งที่เปลี่ยนไปเมื่อย้ายไปใช้ 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 .

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

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

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

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

Ubuntu และ Debian จัดทำแพ็กเกจเกือบทั้งหมดในคลังซอฟต์แวร์สำหรับสถาปัตยกรรม arm64 ดังนั้น apt install nginx postgresql redis-server จึงทำงานเหมือนกันในทั้งสองสถาปัตยกรรม ปัญหาจะเกิดขึ้นกับคลังซอฟต์แวร์จากภายนอก (third party repositories) เป็นหลัก

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

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

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

จากนั้นให้อ่านผลลัพธ์ของ apt update แทนการเลื่อนผ่านไป คลังซอฟต์แวร์ของผู้จำหน่ายที่รองรับเฉพาะ 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'

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

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

รันไทม์แบบ Interpreted และ bytecode ถูกออกแบบมาให้พกพาได้อยู่แล้ว 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) จะสร้างรหัสเครื่องในขณะที่โปรแกรมทำงาน จึงจำเป็นต้องมีตัวสร้างรหัสสำหรับสถาปัตยกรรมเป้าหมายนั้นๆ ซึ่งเวอร์ชันปัจจุบันรองรับทั้งหมด ไม่ว่าจะเป็น OpenJDK, .NET, V8 engine ภายใน Node.js และ PyPy ต่างรองรับ arm64 บน Linux ทั้งสิ้น สิ่งที่เป็นอันตรายจริงๆ คือการใช้เวอร์ชันเก่าที่ถูกล็อกไว้ สคริปต์การติดตั้งที่ดึงรันไทม์เวอร์ชันเมื่อหลายปีก่อนมาใช้ ควรได้รับการตรวจสอบกับบันทึกประจำรุ่น (release notes) ของเวอร์ชันนั้นๆ ว่ารองรับ aarch64 หรือไม่ แทนที่จะทึกทักเอาเองว่าใช้งานได้

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

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

เคอร์เนลและขนาดหน้าหน่วยความจำ: จุดที่อินสแตนซ์ ARM ยังคงมีความแตกต่าง

เซิร์ฟเวอร์ 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 บนอินสแตนซ์และอ่านค่าตัวเลขที่ได้ แทนที่จะคาดเดาเอาเอง

มีความแตกต่างเล็กน้อยอื่นๆ ที่ควรทราบ บน 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 โดยใช้ 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 ระบุประเภทเครื่องที่แตกต่างกัน จึงปฏิเสธการทำงาน บน host แบบ arm64 นี่มักหมายถึง binary หรือ container image แบบ x86-64 โดย Docker จะแสดงคำเตือนก่อนว่า platform ของ image ที่ร้องขอคือ linux/amd64 ไม่ตรงกับ platform ของ host ที่ตรวจพบคือ linux/arm64/v8 วิธีแก้ไขคือการ build สำหรับสถาปัตยกรรมที่ถูกต้อง ไม่มีการตั้งค่าใดที่ทำให้ binary แบบ x86-64 ทำงานแบบ native บน ARM ได้

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

ใช่ ทั้งสองชื่อนี้ใช้เรียกชุดคำสั่ง ARM แบบ 64-bit เหมือนกัน โดย kernel จะรายงานเป็น aarch64 ผ่านทาง uname -m ในขณะที่การจัดแพ็กเกจของ Debian และ Ubuntu รวมถึง string ของ Docker platform จะใช้ 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 ต่อไป