ARM VPS vs x86 VPS: உண்மையில் மாறுவது என்ன?

ARM VPS-க்கு மாறும்போது ஏற்படும் மாற்றங்கள்

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

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

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

வேறு எந்தச் செயலையும் செய்வதற்கு முன், எந்த instance-லிலும் இவற்றை இயக்கவும்.

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

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

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

containers முதலில் ஏன் செயலிழக்கின்றன, பிழை எப்படி தோன்றும்

ஒவ்வொரு Docker image manifest-உம் அது எந்த architecture-க்காக build செய்யப்பட்டது என்பதைப் பதிவு செய்கிறது. amd64 manifest மட்டும் கொண்ட image-ஐ arm64 host-ல் pull செய்தாலும், அந்த pull வெற்றிகரமாக முடியும். முதல் process start செய்யும் போதுதான் failure ஏற்படும்:

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, இந்த CPU செயல்படுத்தாத machine type-ஐ குறிப்பிடுகிறது. எந்த setting-மும் இதைச் சரிசெய்யாது. அந்த instructions இந்த silicon-ல் இல்லை.

Deploy செய்வதற்கு முன் manifest-ஐச் சரிபார்க்கவும்:

docker buildx imagetools inspect nginx:1.27

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

நீங்கள் உருவாக்கும் images-க்கு, ஒரே command-ல் இரண்டு architectures-க்காக build செய்து manifest list-ஐ push செய்யவும்:

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

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

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

Build செய்யவும் test செய்யவும் emulation-ஐப் பயன்படுத்தவும். Traffic-ஐ serve செய்ய emulation-ஐப் பயன்படுத்த வேண்டாம். QEMU உடன் emulation செய்வது “native builds-ஐவிட மிகவும் மெதுவாக இருக்கலாம்; குறிப்பாக compilation மற்றும் compression அல்லது decompression போன்ற அதிக compute தேவைப்படும் பணிகளில்” என Docker-ன் சொந்த documentation குறிப்பிடுகிறது. எனவே ARM instance-ல் emulated x86 service இயக்கினால், நீங்கள் architecture மாற்றியதன் மூலம் பெற நினைத்த saving மீண்டும் இழக்கப்படும். Native case-க்கான host setup இரண்டு architectures-லும் ஒரே மாதிரியாகும்: VPS-ல் Docker இயக்குதல் இதை விளக்குகிறது. மேலும், அதில் உள்ள ஒவ்வொரு image-க்கும் arm64 manifest இருந்தால், ஏற்கனவே உள்ள Compose file எந்த மாற்றமும் இல்லாமல் செயல்படும்.

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

Ubuntu மற்றும் Debian ஆகியவை தங்களின் archive-ஐ கிட்டத்தட்ட முழுமையாக arm64-க்காக build செய்கின்றன. எனவே 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-ன் reporting Candidate: (none) என்பது, enabled நிலையில் உள்ள எந்த repository-யும் அந்த package-க்கான build-ஐ இந்த architecture-க்கு வெளியிடவில்லை என்பதைக் குறிக்கும். apt-get install -s install-ஐ simulate செய்து எதையும் எழுதாது. இதே நிலை ஏற்பட்டால், அது E: Unable to locate package-உடன் முடிவடையும்.

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

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

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

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

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

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

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

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

Production-ஐ நேரடியாகப் பாதிக்கும் முக்கிய வேறுபாடு page size ஆகும். பெரும்பாலான arm64 kernels 4 KiB pages-ஐ பயன்படுத்துகின்றன; இது x86-64-லும் அதேதான். சில kernels 64 KiB pages-ஐ பயன்படுத்துகின்றன. Red Hat Enterprise Linux 8 for aarch64, இயல்பாக 64 KiB page kernel-ஐ வழங்கியது. RHEL 9-ல் இயல்புநிலை மீண்டும் 4 KiB-ஆக மாற்றப்பட்டது; அதே நேரத்தில் பெரிய page size தேவைப்படும் workloads-க்காக தனியான kernel-64k package-ஐ வைத்திருக்கிறது. பல சிறிய mappings கொண்ட process-க்கு 64 KiB page size அதிக memory floor-ஐ உருவாக்கும்; காரணம், kernel வழங்கக்கூடிய குறைந்தபட்ச chunk அளவு பதினாறு மடங்கு பெரியதாகும். Instance-ல் getconf PAGESIZE-ஐ இயக்கி அந்த எண்ணைப் பார்க்கவும்; அதை ஊகிக்க வேண்டாம். உங்கள் system-ஐ அடையும் ஒரே kernel முடிவு page size அல்ல. Provider வழங்கும் kernel version, work cores-க்கு எவ்வாறு schedule செய்யப்படுகிறது என்பதையும் தீர்மானிக்கும். மேலும், Linux 7.2-ல் சேர்க்கப்பட்ட cache-aware scheduling arm64 மற்றும் x86-64 இரண்டிலும் கிடைக்கிறது.

மேலும் சில சிறிய வேறுபாடுகளையும் அறிந்திருப்பது பயனுள்ளது. arm64-ல் operating system CPU microcode package இல்லை. எனவே firmware updates apt மூலம் அல்ல, உங்கள் provider மூலம் வழங்கப்படும். 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 features-க்கு ARM-ல் இணையான counterpart எதுவும் இல்லை.

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

Software தரப்பில், ஆம். Debian, Ubuntu, Fedora மற்றும் RHEL ஆகிய அனைத்தும் first-class arm64 builds-ஐ வெளியிடுகின்றன. Docker Hub-இல் உள்ள official images-ம் வழக்கமாக multi-arch ஆக உள்ளன.

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

அதே announcement-ல் உள்ள caveats-ஐப் படிக்கவும். Officially supported ARM server hardware இன்னும் எவ்வளவு குறுகிய வரம்பில் உள்ளது என்பதை அவை காட்டுகின்றன. Proxmox, NVIDIA மற்றும் Supermicro உடன் Grace Hopper hardware-ல் கூட்டு testing செய்த பிறகு, முதல் நாளிலேயே NVIDIA Grace மற்றும் NVIDIA Vera systems-ஐ validate செய்தது. பிற UEFI-based ARMv8-A மற்றும் ARMv9-A hardware-க்கு best-effort support மட்டுமே வழங்கப்படுகிறது. Device tree-ஐ மட்டுமே பயன்படுத்தும் Raspberry Pi போன்ற single-board computers ஆதரிக்கப்படுவதில்லை. Guest ஒன்று அதன் சொந்த architecture கொண்ட node-ல் மட்டுமே இயங்கும். Live migration, ஒரே architecture கொண்ட nodes-களுக்கு இடையில் மட்டுமே செயல்படும். Mixed-architecture clusters officially supported அல்ல.

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

Commit செய்வதற்கு முன் இயக்க வேண்டிய checklist

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

இந்தப் பதிவு கூறாதது

ARM மற்றும் x86 ஆகியவற்றுக்கான price-to-performance ratio-ஐ நாங்கள் வழங்கப்போவதில்லை. ஒவ்வொரு core-க்கான விலையும் provider மற்றும் plan அடிப்படையில் மாறுபடும். பிறரின் hardware-ல் அளவிடப்பட்ட number, உங்கள் hardware-ன் செயல்திறனை முன்கணிக்காது. அதற்குப் பதிலாக, நீங்களே அளவிடுங்கள். VPS benchmarking-க்கான எங்கள் வழிகாட்டி-ல் sysbench மற்றும் fio ஆகியவற்றை மீண்டும் செய்யக்கூடிய method மூலம் பயன்படுத்துவது விளக்கப்பட்டுள்ளது. VPS-ன் உண்மையான செலவு ஒப்பீட்டின் pricing பகுதியை விளக்குகிறது. Storage, CPU architecture-இலிருந்து தனியான முடிவாகும். VPS-ல் NVMe-யை SATA SSD-உடன் ஒப்பிடுவது எப்படி அந்தப் பகுதியை விளக்குகிறது. இரண்டு plans-லுமே அதே test-ஐ இயக்குங்கள். சாத்தியமான இடங்களில், உங்கள் சொந்த workload-ஐப் பயன்படுத்துங்கள். உங்கள் numbers அடிப்படையில் முடிவு செய்யுங்கள்.

FAQ

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

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

ARM server-ல் exec format error என்றால் என்ன?

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

arm64 மற்றும் aarch64 ஒன்றேதானா?

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

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

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

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

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