ARM на VDS: производительность PHP/Node, совместимость и экономия ресурсов

Зачем вообще смотреть на ARM в VDS

До недавнего времени ARM ассоциировался с мобильными устройствами. Сегодня это зрелая серверная платформа с 64-битной архитектурой (aarch64), современными наборами инструкций и сильной энергетической эффективностью. Для проектов, где затраты на вычисления и тепло — критичны, ARM в составе VDS всё чаще оказывается рациональным выбором. Особенно это заметно на типичных веб-стэках: PHP-FPM с Nginx или Node.js с обратным прокси, где доминируют I/O и сериализация JSON, а также криптография TLS. Для TLS-производительности не забывайте корректно выпустить и установить SSL-сертификаты.

Главные тезисы, которые подтверждают практику эксплуатации:

• Сопоставимая или лучшая производительность на реальных сценариях бэкенда (PHP/Node.js) при меньшем тепловыделении.
• Созревшая экосистема пакетов: дистрибутивы, Docker-образы, большинство популярных расширений PHP и нативных модулей Node уже имеют ARM64-сборки.
• Простая миграция: для 80–90% проектов перенос — это пересборка контейнеров и «npm rebuild» там, где есть нативные зависимости.

Если вы выбираете между веб-серверами, обратите внимание на сравнение стеков в материале Nginx vs Apache: что выбрать в 2025.

Коротко об архитектуре: что такое ARM64 в серверах

Под «ARM на VDS» чаще всего понимают виртуальные машины на ядрах ARMv8/ARMv9 (aarch64). Для нас важно:

• Наличие SIMD-блока NEON и расширений crypto, которые ускоряют AES/GCM, SHA и другие операции TLS.
• Высокая энергоэффективность, позволяющая провайдерам давать более привлекательные тарифы на vCPU при том же TDP стойки.
• Отсутствие AVX2/AVX-512: специализированные x86-оптимизации некоторых бинарей недоступны, но для веб-сервисов это редко становится блокером.

Большинство современных дистрибутивов выпускаются с репозиториями для ARM64, а Docker-образы стали мультиархитектурными по умолчанию. Это означает, что для базовых образов и системных пакетов «совместимость из коробки» уже реальность.

Производительность PHP на ARM

PHP 8.2/8.3 на ARM показывает зрелую производительность: OPcache и JIT поддерживаются на aarch64, а шифрование на OpenSSL обычно ускоряется за счёт аппаратного crypto. Практически для всех «боевых» расширений доступна сборка под ARM64: intl, gd, imagick, pdo_mysql, pdo_pgsql, redis, amqp, grpc, swoole и т.д. Если вы используете редкие проприетарные модули — это единственное место, где стоит проверить совместимость заранее.

Типичный стек для WordPress, Bitrix, Laravel, Symfony — это I/O, сериализация, шаблоны, кэширование, работа с Redis и базой данных. На таких нагрузках ограничителем чаще выступает сеть и дисковая подсистема, а не чистая арифметика CPU. Здесь ARM практически не уступает x86 при аналогичных лимитах vCPU/памяти, а иногда оказывается быстрее за счёт ускоренной криптографии и хорошего кеширования инструкций. Для кеширования объекта/сессий посмотрите наш разбор Redis для PHP: сессии и object cache.

Как мы замеряем

Простая методика, чтобы оценить ваш проект на ARM перед переездом:

1. Идентичные окружения: один стенд на x86-64 и один на ARM64 с одинаковыми лимитами vCPU/RAM/диска.
2. Сборка приложения на каждой архитектуре отдельно (без эмуляции).
3. Холодные и тёплые прогоны с кешами (OPcache, кэш-шаблонов) и без них.
4. Нагрузочный тест с ростом RPS до первого стабильного плато по latency.

uname -m
php -v
php -m
php-fpm8.3 -tt
wrk -t4 -c128 -d60s http://127.0.0.1/app/health

На ARM обратите внимание на параметры менеджера процессов PHP-FPM: из-за иной частоты и энергобюджетов «правильное» количество воркеров может отличаться. Признак оптимума — стабильная p95/p99 latency и отсутствие роста очереди при ~70–80% загрузке CPU. Убедитесь, что pm.max_children не упирается в RAM, а pm.max_requests достаточно мал, чтобы избегать утечек, но не слишком, чтобы не штрафовать подогрев кешей.

Производительность Node.js на ARM

Node.js уже много релизов поставляет официальные бинарники для ARM64, а движок V8 стабильно умеет JIT-компиляцию под aarch64. На типичных API-сервисах (Express, Fastify, NestJS) ограничения чаще в базе данных и сети, а не в CPU. Если же у вас много CPU-bound задач (парсинг, сжатие, картинка), смотрите на нативные модули и их поддержку ARM.

Ключевые моменты:

• Почти все популярные нативные зависимости имеют prebuild для ARM64 через N-API: bcrypt, sharp, canvas, grpc, lmdb, better-sqlite3, node-rdkafka и т.п.
• Где prebuild нет, помогает node-gyp с локальными dev-заголовками. Важно иметь установленный компилятор и соответствующие dev-пакеты.
• SSR/SSG (Next.js, Nuxt) работают штатно; сборка на ARM обычно не отличается по шагам. Следите за зависимостями, которые тянут системные бинарники (например, для PDF/картинок).

node -v
npm ci
npm rebuild --build-from-source
npx autocannon -c 128 -d 60 http://127.0.0.1:3000/health

Если задействуются внешние бинарники, как Chromium для Puppeteer или ffmpeg, проверьте наличие ARM64-сборок в репозитории дистрибутива. Для Puppeteer можно использовать PUPPETEER_SKIP_DOWNLOAD=1 и указывать системный Chromium, если автоматическая загрузка не поддерживает вашу архитектуру.

Совместимость: ОС, пакеты, контейнеры

Современные Ubuntu/Debian/AlmaLinux и другие серверные дистрибутивы имеют полноценные репозитории для ARM64. Базовые вещи вроде Nginx, OpenSSL, systemd, libc, компиляторов — в нативных сборках, поддержка на уровне ядра сопоставима с x86-64.

Контейнеры. Сегодня большинство официальных образов имеют манифесты для нескольких архитектур. Важно собирать и запускать именно нативные ARM64-образы, а не эмулировать x86 через qemu-user (под нагрузкой эмуляция заметно дороже).

# Проверка архитектуры хоста
uname -m

# Включаем buildx и собираем multi-arch образ
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 -t registry.example/app:latest --push .

# На ARM-хосте можно явно указать платформу
docker run --platform linux/arm64 registry.example/app:latest

В Compose-файле фиксируйте платформу сервиса, если собираетесь разворачивать один и тот же стек на разных архитектурах:

services:
  api:
    image: registry.example/app:latest
    platform: linux/arm64
    environment:
      - NODE_ENV=production
    ports:
      - "3000:3000"

PHP-расширения в контейнере под ARM собираются обычно теми же командами, что и под x86, просто берутся arm64-пакеты. Если используете Alpine, внимательно к библиотекам musl: некоторые закрытые бинарники ожидают glibc; для них предпочтителен Debian/Ubuntu base image.

Распространённые грабли и обходные пути

• Отсутствует prebuild нативной зависимости Node: выполните npm rebuild --build-from-source, добавьте dev-пакеты (build-essential, python3, заголовки соответствующих библиотек). Для sharp — libvips-dev, для canvas — cairo, pango, jpeg.
• Puppeteer не находит Chromium: установите системный chromium из репозитория и задайте путь в конфиге запуска. Либо используйте headless-браузеры с готовыми ARM64-сборками.
• Проприетарный x86-бинарь: проверьте, есть ли ARM64-версия или эквивалент. Эмуляцию для продакшена не применяйте: задержки и потребление CPU резко вырастут.
• Образы базы данных: используйте официальные multi-arch образы. Убедитесь, что плагины/расширения (например, PostGIS) присутствуют в ARM64-билдах.
• Сжатие и шифрование: на ARM используйте современные алгоритмы: zstd вместо gzip в бэкапах, TLS 1.3 с AES-GCM/ChaCha20-Poly1305, что нередко быстрее за счёт NEON/crypto.

Экономия: где она возникает и как оценить

Экономия на ARM складывается из двух компонентов: ресурсной (меньше ватт на ядро — провайдер может дать более выгодную цену на vCPU) и эксплуатационной (на ту же нагрузку хватает меньшего количества ядер или более низкого такта, если узким местом не является чистая арифметика).

Как оценивать выгоду:

1. Снимите профили нагрузки на текущем x86: RPS, p95/99 latency, CPU%, системные метрики TLS и сериализации.
2. Разверните эквивалентный ARM-стенд и повторите замеры. Сравните RPS на одинаковых p95/99.
3. Если ARM даёт ту же пропускную способность на меньшем количестве vCPU — это ваш запас экономии. Если же RPS упирается в однопоточную производительность (рендеринг, сжатие, специфический код) — экономия может нивелироваться.

В реальных веб-проектах с кэшем на уровне Nginx и приложений, а также с грамотной конфигурацией PHP-FPM/Node кластеризации, ARM часто показывает такой же или лучший RPS на ядро при схожей или меньшей задержке. На фоновых задачах, вроде компрессии изображений, результаты зависят от конкретных библиотек.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Когда ARM может не подойти

• Есть критичные бинарные зависимости только для x86 и нет альтернатив.
• Используется ПО, оптимизированное под AVX2/AVX-512 без ARM-порта (научные/ML-библиотеки, проприетарные аналитические модули).
• Жёсткие требования к однопоточной производительности узкого куска кода, который невозможно распараллелить или переписать.

В остальных случаях — особенно для типичных веб-приложений, API и SSR — ARM оправдывает ожидания.

Переезд на ARM VDS: чек-лист

1. Соберите инвентаризацию зависимостей. PHP-расширения, Node-модули с нативными частями, внешние бинарники (chromium, wkhtmltopdf, ffmpeg), драйверы БД/кеша.
2. Готовим ARM-окружение. Выберите дистрибутив, установите компилятор и dev-пакеты, если нужны сборки зависимостей.
3. Соберите нативные образы. Для Docker используйте buildx и multi-arch, но деплойте именно ARM64.
4. Сборка и тесты. Прогоните unit/integration, затем горячие e2e с живой базой-клоном или фикстурами.
5. Нагрузочное тестирование. Зафиксируйте целевые SLO (RPS, p95/99) и сравните x86 vs ARM. Подстройте количество воркеров PHP-FPM/Node cluster.
6. Наблюдаемость. Экспортеры CPU/memory/IO, логи, трассировка; проверьте, что алерты настроены с учётом новой платформы.
7. План отката. На случай регрессии — keep-alive x86-сборки и инфраструктурные манифесты.

Практические команды и конфигурации

Диагностика архитектуры и пакетов:

uname -m
cat /etc/os-release
dpkg --print-architecture
apt update
apt install -y php8.3-fpm php8.3-cli php8.3-opcache php8.3-redis
systemctl status php8.3-fpm

Node-модули с нативной сборкой:

apt install -y build-essential python3 pkg-config libcairo2-dev libjpeg-dev libpango1.0-dev libgif-dev librsvg2-dev
npm ci
npm rebuild --build-from-source

Dockerfile пример для Node SSR с natively arm64-friendly образом:

FROM node:20-bookworm-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build
CMD ["node", "server.js"]

Dockerfile для PHP-FPM с включённым OPcache:

FROM debian:12-slim
RUN apt update && apt install -y php8.3-fpm php8.3-cli php8.3-opcache && rm -rf /var/lib/apt/lists/*
COPY . /var/www/html
CMD ["php-fpm8.3", "-F"]

Мини-FAQ

Нужно ли что-то особенное на уровне ядра/системы для ARM?

Нет. Современные образы дистрибутивов работают «из коробки». Главное — выбирать актуальные версии с полноценной поддержкой ARM64.

Будет ли PHP медленнее без AVX2?

Для типичных веб-нагрузок нет. Узкие места — сеть, диски, шаблоны, сериализация. Криптография может быть даже быстрее за счёт ARM crypto.

Node.js и нативные модули — где ждать проблем?

Когда нет prebuild для ARM64 и требуется локальная сборка. Подготовьте dev-пакеты и используйте npm rebuild. Библиотеки для обработки изображений — самая частая зона внимания.

Миграция контейнеров — это боль?

Если соблюдаете best practices (multi-arch манифесты, сборка на той же архитектуре, отказ от эмуляции на проде) — проходит гладко. Учтите разницу в базовых образах glibc vs musl.

В чём реальная экономия?

Возможность получить ту же пропускную способность на меньшем числе vCPU и сократить энергопотребление стойки. Но подтверждайте тестами именно вашего приложения.

Выводы

ARM на VDS — уже не эксперимент, а рабочий инструмент для большинства PHP и Node.js проектов. Производительность на реальных веб-нагрузках сопоставима с x86, а иногда и выше; совместимость экосистемы высока; миграция при должной подготовке предсказуема. Экономию даёт сочетание энергоэффективности и адекватного ценообразования на vCPU. Проведите короткий POC с нагрузочными тестами, убедитесь в совместимости редких зависимостей — и смело переводите окружения, где это оправдано по SLO и бюджету.