ARM VPS vs x86 VPS: முக்கிய வேறுபாடுகள் என்ன?

ARM VPS-க்கு மாறும்போது என்ன மாற்றங்கள் நிகழும்

ஒரு ARM VPS-ல் x86 VPS-ல் இயங்குவது போன்ற அதே Linux மற்றும் Nginx-தான் இயங்கும், மேலும் இது பொதுவாக ஒரு core-க்கு குறைந்த செலவிலேயே கிடைக்கும். மாறுதலில் உள்ள ஆபத்து இணக்கத்தன்மை (compatibility) சார்ந்தது. x86-64-க்காக compile செய்யப்பட்ட ஒரு நிரல் arm64-ல் இயங்காது, எனவே உங்கள் stack-ல் உள்ள ஒவ்வொரு மென்பொருளும் arm64 build-ஐக் கொண்டிருக்க வேண்டும் அல்லது அதை நீங்கள் மீண்டும் build செய்யக்கூடியதாக இருக்க வேண்டும்.

பெரும்பாலான நவீன stack-கள் எந்த மாற்றமும் இன்றி இந்தச் சோதனையில் தேர்ச்சி பெறுகின்றன. தோல்விகள் பொதுவாக இரண்டு இடங்களில் நிகழ்கின்றன: ஒரு குறிப்பிட்ட architecture-க்காக மட்டுமே உருவாக்கப்பட்ட container images மற்றும் arm64 பதிப்பு இல்லாத closed source மென்பொருள்கள். நீங்கள் ஒரு instance-க்கு பணம் செலுத்தும் முன்பே, உங்கள் stack-ல் உள்ள இந்த இரண்டு சிக்கல்களையும் சரிபார்க்க கீழே உள்ள கட்டளைகள் உதவும். உங்களுக்கு எந்த வகையான server தேவை என்பதை இன்னும் முடிவு செய்யவில்லை என்றால், VPS என்றால் என்ன மற்றும் அது shared hosting-லிருந்து எவ்வாறு வேறுபடுகிறது என்பதிலிருந்து தொடங்கவும்.

arm64, aarch64, amd64: எந்தப் பெயர் எதைக் குறிக்கிறது

எந்தவொரு பணியையும் தொடங்கும் முன், எந்தவொரு instance-லும் இவற்றை இயக்கவும்.

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

uname -m கட்டளையானது ARM இயந்திரத்தில் aarch64 என்றும், Intel அல்லது AMD இயந்திரத்தில் x86_64 என்றும் வெளியிடும். dpkg --print-architecture கட்டளையானது அதே இரண்டு இயந்திரங்களுக்கும் முறையே arm64 மற்றும் amd64 என்று வெளியிடும். இரண்டு பதில்களும் சரியானவைதான். Linux kernel மற்றும் Debian packaging system ஆகியவை ஒரே instruction set-க்கு வெவ்வேறு பெயர்களைத் தேர்ந்தெடுத்துள்ளன. எனவே, aarch64 மற்றும் arm64 ஆகியவை ஒரு பொருளையும், x86_64 மற்றும் amd64 ஆகியவை மற்றொரு பொருளையும் குறிக்கின்றன. Docker, Debian பாணிப் பெயர்களைப் பயன்படுத்துகிறது, இதனால்தான் image platform-ல் linux/arm64 என்று காட்டப்படுகிறது.

arm64-ல் /proc/cpuinfo கோப்பில் model name வரி இருக்காது. அதற்குப் பதிலாக Features என்ற புலம் (field) இருக்கும், அதில் aes pmull sha1 sha2 போன்ற hardware crypto கொடிகள் (flags) காணப்படும். இவை ARMv8 Cryptographic Extensions ஆகும். இவை Intel மற்றும் AMD பாகங்களில் AES-NI செய்யும் அதே வேலையைச் செய்கின்றன: இவை TLS (transport layer security) மற்றும் disk encryption ஆகியவற்றை hardware மட்டத்தில் வேகப்படுத்துகின்றன. VPS-ல் AES hardware acceleration-ஐச் சரிபார்த்தல் என்ற பகுதி, இரண்டு architectures-லும் இதைச் சோதிக்கும் முறையை விளக்குகிறது.

கண்டெய்னர்கள் ஏன் முதலில் செயலிழக்கின்றன மற்றும் பிழை எவ்வாறு தோன்றும்

ஒவ்வொரு Docker image manifest-ம் அது எந்த architecture-க்காக உருவாக்கப்பட்டது என்பதைப் பதிவு செய்கிறது. amd64 manifest-ஐ மட்டுமே கொண்ட ஒரு image-ஐ arm64 host-க்கு pull செய்தால், pull செயல்முறை வெற்றிகரமாக முடியும். ஆனால், முதல் 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 என்பது kernel அந்த file-ஐ இயக்க மறுப்பதாகும். ஏனெனில், அதன் ELF (executable and linkable format) header-ல் உள்ள machine type-ஐ இந்த CPU-வால் செயல்படுத்த முடியாது. எந்த அமைப்பும் (setting) இதைச் சரிசெய்யாது. அந்த instruction-கள் இந்த silicon-ல் இல்லை.

நீங்கள் deploy செய்வதற்கு முன் manifest-ஐச் சரிபார்க்கவும்:

docker buildx imagetools inspect nginx:1.27

இந்த output, manifest list-ல் உள்ள ஒவ்வொரு image-க்கும் ஒரு Platform: வரியைப் பட்டியலிடும், உதாரணமாக linux/amd64 மற்றும் linux/arm64. ஒருவேளை linux/arm64 இல்லையென்றால், அந்த tag ஒரு ARM VPS-ல் இயங்காது. docker manifest inspect --verbose nginx:1.27 அதே தகவலைக் காட்டுகிறது, ஆனால் Docker ஆவணங்கள் docker manifest-ஐ ஒரு experimental command-ஆகக் குறிப்பிடுகின்றன. இதன் செயல்பாடு release-களுக்கு இடையே மாறக்கூடும் என்பதால், imagetools-ஐப் பயன்படுத்துவதே சிறந்தது.

நீங்களே உருவாக்கும் image-களுக்கு, ஒரே கட்டளையில் இரண்டு architecture-களையும் உருவாக்கி, ஒரு manifest list-ஐ push செய்யவும்:

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

ஒரே host-ல் வேறொரு architecture-க்காக build செய்ய, kernel-ன் binfmt_misc handler-ல் பதிவு செய்யப்பட்ட QEMU user mode emulation தேவை:

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

Emulation-ஐ build செய்யவும் சோதிக்கவும் பயன்படுத்தவும். traffic-ஐக் கையாள (serve) இதைப் பயன்படுத்த வேண்டாம். Docker-ன் சொந்த ஆவணங்களின்படி, QEMU உடனான emulation "native build-களை விட மிக மெதுவாக இருக்கலாம், குறிப்பாக compilation மற்றும் compression அல்லது decompression போன்ற அதிக compute தேவைப்படும் பணிகளுக்கு" என்று கூறப்பட்டுள்ளது. எனவே, ஒரு ARM instance-ல் emulated x86 service-ஐ இயக்குவது, நீங்கள் அந்த architecture-க்கு மாறியதன் நோக்கத்தையே (சேமிப்பு) வீணாக்கிவிடும். Native சூழலுக்கான host அமைப்பு இரண்டு architecture-களிலும் ஒரே மாதிரியாகவே இருக்கும்: VPS-ல் Docker-ஐ இயக்குதல் இதைப் பற்றி விளக்குகிறது. ஒரு Compose file-ல் உள்ள அனைத்து image-களும் arm64 manifest-ஐக் கொண்டிருந்தால், அந்த file-ஐ மாற்றமின்றி அப்படியே பயன்படுத்தலாம்.

எனக்குத் தேவையான packages arm64-ல் கிடைக்குமா?

Ubuntu மற்றும் Debian ஆகியவை தங்களின் முழு archive-ஐயும் arm64-க்காக உருவாக்குகின்றன, எனவே apt install nginx postgresql redis-server இரண்டு architectures-லும் ஒரே மாதிரியாகச் செயல்படும். மூன்றாம் தரப்பு (third party) repositories-ல் தான் பற்றாக்குறைகள் இருக்கலாம்.

ARM instance-ல் நேரடியாக apt-இடம் கேட்கவும்:

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

apt-cache policy என்பது Candidate: (none) என்று காட்டினால், எந்தவொரு enabled repository-யும் அந்த architecture-க்கான package build-ஐ வெளியிடவில்லை என்று அர்த்தம். apt-get install -s என்பது நிறுவுதலைச் சோதிக்கும் (simulate) மற்றும் எதையும் எழுதாது, அதே சூழலில் அது E: Unable to locate package என்று முடிவடையும்.

பிறகு, apt update வெளியீட்டைத் தள்ளிப் பார்ப்பதற்குப் பதிலாக நேரடியாக வாசிக்கவும். amd64-க்கு மட்டுமேயான vendor repository இதைக் குறிப்பிடும்:

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 சரியாக உள்ளமைக்கப்பட்டு அணுகக்கூடியதாக உள்ளது, ஆனால் இந்த machine-ல் நிறுவக்கூடிய எதையும் அது கொண்டிருக்கவில்லை. Source entry-யையும் சரிபார்க்கவும். [arch=amd64] என்று pinned செய்யப்பட்ட ஒரு வரி arm64 host-ல் தவிர்க்கப்படும், எனவே உண்மையான காரணம் அந்த pin ஆக இருக்கும்போது, package விடுபட்டது போலத் தோன்றும்.

எந்தெந்த workloads பாதுகாப்பானவை, எவற்றை முதலில் சரிபார்க்க வேண்டும்

Interpreted மற்றும் bytecode runtimes வடிவமைப்பிலேயே portable ஆனவை. PHP, Python, Ruby மற்றும் Node.js ஆகியவற்றின் arm64 packages முக்கிய Linux distributions-களில் கிடைக்கின்றன. Go மற்றும் Rust ஆகியவற்றை ஒரு target-ஐ அமைப்பதன் மூலம் arm64-க்கு cross-compile செய்ய முடியும். ஒரு LEMP stack, Node API, Nginx-க்கு பின்னால் இயங்கும் Go binary அல்லது Postgres database ஆகியவை arm64-ல் சாதாரணமாக இயங்கக்கூடியவை.

Just in time (JIT) compiler நிரல் இயங்கும்போது machine code-ஐ உருவாக்குகிறது, எனவே இதற்கு அந்த target architecture-க்கான code generator தேவை. தற்போதைய பதிப்புகளில் இது உள்ளது: OpenJDK, .NET, Node.js-ல் உள்ள V8 engine மற்றும் PyPy ஆகிய அனைத்தும் Linux-ல் arm64-ஐ ஆதரிக்கின்றன. பழைய பதிப்புகளை அப்படியே பயன்படுத்துவதுதான் உண்மையான ஆபத்து. பல ஆண்டுகளுக்கு முந்தைய runtime release-ஐ நிறுவும் deploy script-ஐப் பயன்படுத்தும் முன், அது aarch64-ஐ ஆதரிக்கிறதா என்பதை அந்த release-ன் குறிப்புகளில் சரிபார்க்க வேண்டும்; அது தானாகவே வேலை செய்யும் என்று கருதக்கூடாது.

கையால் எழுதப்பட்ட x86 assembly அல்லது SSE மற்றும் AVX intrinsics-ஐக் கொண்ட libraries அமைதியான சிக்கலை ஏற்படுத்துபவை. பெரும்பாலானவற்றில் NEON path (NEON என்பது ARM vector instruction set) அல்லது சாதாரண C fallback வசதி இருப்பதால், அவை compile ஆகி இயங்கும். x86 build-ஐ விட இவற்றின் செயல் திறன் (performance) மாறுபடலாம். கட்டுரைகளைப் பார்த்து ஊகிப்பதை விட, உங்கள் instance-ல் அதை அளந்து பார்ப்பதே சிறந்தது.

Closed source மென்பொருட்கள் உண்மையான தடையாகும். ஒரு vendor monitoring agent, உரிமம் பெற்ற database driver, வணிக ரீதியான control panel அல்லது anti-virus daemon ஆகியவை compiled binary-ஆகவே வருகின்றன. vendor arm64 build-ஐ வெளியிடவில்லை என்றால், நீங்கள் எதையும் செய்ய முடியாது. hosting துறையில் cPanel மற்றும் WHM இதற்கு மிகச்சிறந்த உதாரணம்: அதன் system requirements-ல் x86_64 மட்டுமே குறிப்பிடப்பட்டுள்ளது, ARM குறிப்பிடப்படவில்லை. எனவே, control panel server-ஐ x86-லேயே வைத்திருக்க வேண்டும் (ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்டது, vendor-ன் சொந்த requirements பக்கத்தில் மீண்டும் ஒருமுறை சரிபார்ப்பது நல்லது). இது மட்டுமே உங்களைத் தடுக்கும் காரணியாக இருந்தால், VPS-ல் இயக்கக்கூடிய cPanel மாற்றுகள் பகுதியில் தொடங்கி, ஒவ்வொன்றின் architecture ஆதரவையும் இதே முறையில் சரிபார்க்கவும்.

Kernels மற்றும் page size: ARM instances-ல் இன்னும் வேறுபடும் இடங்கள்

x86-64 servers பெரும்பாலும் ஒன்றுக்கொன்று மாற்றத்தக்கவை. ARM servers அவ்வளவு சீரானவை அல்ல, மேலும் இந்த வேறுபாடுகள் உங்கள் application-க்கு அடியில் உள்ளன.

Page size என்பது production-ஐ பாதிக்கும் ஒரு காரணியாகும். பெரும்பாலான arm64 kernels, x86-64-ஐப் போலவே 4 KiB pages-ஐப் பயன்படுத்துகின்றன. சில 64 KiB-ஐப் பயன்படுத்துகின்றன. aarch64-க்கான Red Hat Enterprise Linux 8 இயல்பாகவே 64 KiB page kernel-ஐ வழங்கியது, ஆனால் RHEL 9 பெரிய அளவிலான page தேவைப்படும் workloads-க்காக ஒரு தனி kernel-64k தொகுப்பை வைத்துக்கொண்டு, இயல்புநிலையை மீண்டும் 4 KiB-க்கு மாற்றியது. 64 KiB page size, பல சிறிய mappings கொண்ட ஒரு process-ன் குறைந்தபட்ச நினைவகத் தேவையை (memory floor) உயர்த்துகிறது, ஏனெனில் kernel வழங்கக்கூடிய மிகச்சிறிய பகுதி பதினாறு மடங்கு பெரியதாகிறது. instance-ல் getconf PAGESIZE கட்டளையை இயக்கி, அந்த எண்ணை நீங்களே சரிபார்க்கவும்; அதை ஊகிக்க வேண்டாம்.

தெரிந்துகொள்ள வேண்டிய சில சிறிய வேறுபாடுகள் உள்ளன. arm64-ல் operating system CPU microcode தொகுப்பு எதுவும் இல்லை, எனவே firmware மேம்படுத்தல்கள் உங்கள் வழங்குநரிடமிருந்து (provider) வருமே தவிர, apt-லிருந்து வராது. ARM servers UEFI (unified extensible firmware interface) மூலம் boot ஆகின்றன மற்றும் ACPI (advanced configuration and power interface) மூலம் அவற்றின் வன்பொருளை (hardware) விவரிக்கின்றன. AMD SEV memory encryption மற்றும் Intel GVT-g mediated GPUs உள்ளிட்ட சில x86 அம்சங்களுக்கு ARM-ல் இணையான வசதிகள் எதுவும் இல்லை.

ARM server தளம் முதிர்ச்சியடைந்துள்ளதா?

மென்பொருள் தரப்பில், ஆம். Debian, Ubuntu, Fedora மற்றும் RHEL ஆகிய அனைத்தும் உயர்தர arm64 builds-ஐ வழங்குகின்றன, மேலும் Docker Hub-ல் உள்ள அதிகாரப்பூர்வ images இயல்பாகவே multi-arch வசதியைக் கொண்டுள்ளன.

இதற்கான மிகத் தெளிவான சமீபத்திய சான்று Proxmox ஆகும். 5 August 2026 அன்று, Proxmox Virtual Environment-ன் முதல் அதிகாரப்பூர்வமாக ஆதரிக்கப்படும் arm64 பதிப்பான 9.2-ஐ Proxmox அறிவித்தது. இது x86-64 பதிப்பின் அதே package repositories மற்றும் release lifecycle-ஐப் பகிர்ந்து கொள்கிறது. இது Debian 13.5, Linux 7.0, QEMU 11.0, LXC 7.0 மற்றும் ZFS 2.4 ஆகியவற்றின் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளது. கட்டமைப்பிற்குரிய (architecture specific) சில சிறிய அம்சங்களைத் தவிர, இதன் configuration மற்றும் கருவிகள் x86-64-க்கு இணையானவை.

அதே அறிவிப்பில் உள்ள எச்சரிக்கைகளைப் படிக்கவும், ஏனெனில் அதிகாரப்பூர்வமாக ஆதரிக்கப்படும் ARM server வன்பொருள் இன்னும் எவ்வளவு குறைவாக உள்ளது என்பதை அவை காட்டுகின்றன. Grace Hopper வன்பொருளில் NVIDIA மற்றும் Supermicro நிறுவனங்களுடன் இணைந்து சோதனை செய்த பிறகு, NVIDIA Grace மற்றும் NVIDIA Vera அமைப்புகளை Proxmox முதல் நாளிலேயே உறுதிப்படுத்தியது. பிற UEFI அடிப்படையிலான ARMv8-A மற்றும் ARMv9-A வன்பொருள்கள் சிறந்த முயற்சியின் அடிப்படையில் (best effort) ஆதரிக்கப்படுகின்றன. Device tree மட்டுமே கொண்ட Raspberry Pi போன்ற single board கணினிகள் ஆதரிக்கப்படுவதில்லை. ஒரு guest அதன் சொந்த architecture கொண்ட node-ல் மட்டுமே இயங்கும், live migration ஒரே architecture கொண்ட nodes-க்கு இடையே மட்டுமே செயல்படும், மேலும் கலப்பு architecture கொண்ட clusters அதிகாரப்பூர்வமாக ஆதரிக்கப்படுவதில்லை.

இது August 2026 நிலவரப்படியான உண்மையான நிலைப்பாடு ஆகும். ஒரு hypervisor விற்பனையாளர் x86-64-க்கு இணையான lifecycle-ல் arm64-ஐ வழங்குவது, இந்தத் தளத்திற்கு ஒரு உண்மையான முன்னேற்றமாகும். முதல் நாளில் ஆதரிக்கப்படும் வன்பொருள் பட்டியலில் இரண்டு CPU குடும்பங்கள் மட்டுமே உள்ளன.

நீங்கள் commit செய்வதற்கு முன் சரிபார்க்க வேண்டியவை

1. ஒரு trial instance-ல் uname -m-ஐ இயக்கி, அது aarch64-ஐ வெளியிடுகிறதா என்பதை உறுதிப்படுத்தவும்.
2. உங்கள் Compose file-ல் உள்ள ஒவ்வொரு image-க்கும் docker buildx imagetools inspect-ஐ இயக்கி, ஒவ்வொன்றிற்கும் linux/arm64 platform வரி இருப்பதை உறுதிப்படுத்தவும்.
3. ARM instance-ல் apt update-ஐ இயக்கி, அது வெளியிடும் ஒவ்வொரு Skipping acquire எச்சரிக்கையையும் வாசிக்கவும்.
4. நீங்கள் சார்ந்திருக்கும் ஒவ்வொரு closed source agent-ன் download பக்கத்தைத் திறந்து, arm64 அல்லது aarch64 build பெயரில் உள்ளதா என்று பார்க்கவும்.
5. getconf PAGESIZE-ஐ இயக்கி, memory அளவை நிர்ணயிக்கும் முன் அதன் விடையைக் குறித்துக்கொள்ளவும்.
6. நீங்கள் தேர்வு செய்யவிருக்கும் ARM plan மற்றும் x86 plan ஆகிய இரண்டிலும் உங்கள் சொந்த benchmark-ஐ இயக்கிப் பார்க்கவும்.

இந்தக் கட்டுரை எதை உறுதிப்படுத்தவில்லை

ARM மற்றும் x86 ஆகியவற்றுக்கு இடையேயான விலை மற்றும் செயல்திறன் விகிதத்தை நாங்கள் இங்கே வழங்கப்போவதில்லை. ஒவ்வொரு core-க்கான விலையும் வழங்குநருக்கும் திட்டத்திற்கும் ஏற்ப மாறுபடும்; மற்றவர்களின் hardware-ல் எடுக்கப்பட்ட அளவீடுகள் உங்கள் சூழலுக்குப் பொருந்தாது. அதற்குப் பதிலாக நீங்களே அளவீடு செய்யுங்கள். VPS-ஐ benchmarking செய்வதற்கான எங்கள் வழிகாட்டி sysbench மற்றும் fio ஆகியவற்றை நீங்கள் மீண்டும் செய்யக்கூடிய முறையில் விளக்குகிறது, மேலும் VPS-ன் உண்மையான செலவு ஒப்பீட்டின் விலை சார்ந்த அம்சங்களை விவரிக்கிறது. சேமிப்பகம் (storage) என்பது CPU architecture-லிருந்து தனிப்பட்ட முடிவாகும், VPS-ல் NVMe மற்றும் SATA SSD ஒப்பீடு அந்தப் பகுதியை விளக்குகிறது. முடிந்தவரை உங்கள் சொந்த workload-ஐப் பயன்படுத்தி, இரண்டு திட்டங்களிலும் ஒரே சோதனையைச் செய்து, உங்கள் தரவுகளின் அடிப்படையில் முடிவெடுங்கள்.

FAQ

எனது Docker containers ARM VPS-ல் இயங்குமா?

ஒவ்வொரு image-ன் manifest-லும் linux/arm64 உள்ளீடு இருந்தால் அவை இயங்கும். docker buildx imagetools inspect <image> கட்டளையைப் பயன்படுத்தி ஒவ்வொன்றையும் சரிபார்த்து, Platform: linux/arm64 வரியைத் தேடவும். Docker Hub-ல் உள்ள அதிகாரப்பூர்வமான images பொதுவாக multi-arch முறையில் இருக்கும். சிறிய நிறுவனங்களின் images மற்றும் x86 machine-ல் நீங்கள் உருவாக்கிய images பெரும்பாலும் அவ்வாறு இருக்காது. உங்கள் சொந்த images-க்கு, docker buildx build --platform linux/amd64,linux/arm64 ... --push பயன்படுத்தி மீண்டும் build செய்யவும்; அப்போதுதான் ஒரே tag இரு architectures-க்கும் பொருந்தும்.

ARM server-ல் exec format error என்பதன் பொருள் என்ன?

Kernel ஒரு binary-ஐ இயக்க முயன்றது, ஆனால் அதன் ELF header வேறு machine வகையைக் குறிப்பிட்டதால் அது மறுக்கப்பட்டது. ஒரு arm64 host-ல் இது பெரும்பாலும் x86-64 binary அல்லது container image-ஐக் குறிக்கும். Docker முதலில் ஒரு எச்சரிக்கையைத் தரும், அதில் கோரப்பட்ட image platform linux/amd64, கண்டறியப்பட்ட host platform linux/arm64/v8 உடன் பொருந்தவில்லை என்று குறிப்பிடப்பட்டிருக்கும். சரியான architecture-க்கு build செய்வதே இதற்கான தீர்வு. எந்தவொரு configuration மாற்றமும் x86-64 binary-ஐ ARM-ல் நேரடியாக இயக்க உதவாது.

arm64 மற்றும் aarch64 இரண்டும் ஒன்றா?

ஆம். இவை இரண்டும் 64-bit ARM instruction set-க்கான பெயர்கள். Kernel aarch64 மூலம் uname -m என்று காட்டும், அதே சமயம் Debian மற்றும் Ubuntu packaging, மற்றும் Docker platform strings ஆகியவை arm64 என்று பயன்படுத்தும். இதே போன்ற வேறுபாடு மறுபக்கத்திலும் உள்ளது, அங்கு uname -m என்பது x86_64 என்றும், packaging amd64 என்றும் குறிப்பிடுகிறது. ஒரு download பக்கம் aarch64 கோப்புகளை மட்டுமே வழங்கினால், dpkg --print-architecture-ல் arm64 என்று அழைக்கப்படும் machine-க்கு அவைதான் சரியான கோப்புகள்.

ARM VPS, x86 VPS-ஐ விட வேகமானதா?

இந்தக் கேள்விக்கு பொதுவான பதில் இல்லை. நீங்கள் படிக்கும் எந்தவொரு விகிதமும் உங்களுடையது அல்லாத hardware-ல் அளவிடப்பட்டது. வேகம் என்பது குறிப்பிட்ட CPU model, உங்களுக்கு வழங்கப்பட்ட cores எண்ணிக்கை, வாடிக்கையாளர்களிடையே ஏற்படும் நெரிசலை provider எவ்வாறு கையாளுகிறார், மற்றும் உங்கள் workload vector instructions-ஐ எவ்வளவு சிறப்பாகப் பயன்படுத்துகிறது என்பதைப் பொறுத்தது. நீங்கள் தேர்வு செய்யப்போகும் இரண்டு திட்டங்களை, முடிந்தால் உங்கள் சொந்த workload-ஐக் கொண்டு benchmark செய்து, அந்த எண்களை ஒப்பிட்டுப் பாருங்கள்.

ஒரு production server-ஐ arm64-க்கு மாற்றும் முன் எதைச் சரிபார்க்க வேண்டும்?

இந்த வரிசையில் நான்கு சோதனைகளைச் செய்யவும். ஒவ்வொரு container image-லும் arm64 manifest இருப்பதை உறுதிப்படுத்தவும். ஒவ்வொரு third party apt repository-யும் binary-arm64-ஐ வெளியிடுகிறதா என்று உறுதிப்படுத்தவும். ஒவ்வொரு closed source agent-க்கும் aarch64 download உள்ளதா என்று சரிபார்க்கவும். பிறகு target instance-ல் getconf PAGESIZE-ஐ இயக்கவும், ஏனெனில் 64 KiB page kernel பல சிறிய mappings கொண்ட processes-ன் memory பயன்பாட்டை மாற்றும். இந்த நான்கு சோதனைகளில் எது தோல்வியடைந்தாலும், அந்த குறிப்பிட்ட server-ஐ x86-லேயே வைத்திருப்பது நல்லது.