Black Friday Deals Not Found Anywhere Else! Save up to 55% OFF Hosting, Domains, Pro Services, and more.
Vodien Black Friday Sale applies to new purchase on select products and plans until 4 December 2024. Cannot be used in conjunction with other discounts, offers, or promotions.
Mixpanel Event Tracking for SaaS on Shared Hosting

Core Affinity for Shared-Hosting PHP Workers: A Practical, Safe Guide (taskset, numactl & NUMA awareness)

Locking specific PHP-FPM processes to individual CPU cores, a technique known as CPU pinning or core affinity, supercharges performance by keeping data within the CPU’s local cache. This prevents the “memory amnesia” that occurs when a process jumps from one core to another.

Predictable request latency and lower cache-thrashing are within reach, even on crowded shared servers, once your PHP workers stay on the same cores and, crucially, the same memory bank. Yet blunt CPU pinning can backfire in multi-tenant hosting, starving neighbours or chasing memory across sockets.

This guide shows a low-risk path to core affinity and NUMA-aware binding so you can squeeze more throughput from PHP-FPM without turning the host into a science experiment.

NUMA Awareness and Why Memory Locality Matters More Than CPU-only Pinning

Core affinity pins a process or thread to specific CPU cores. NUMA (Non-Uniform Memory Access) awareness goes a step further by keeping both CPU and memory on the same socket, shrinking the distance each memory fetch travels. On two-socket servers, remote memory can add tens of nanoseconds per access, eroding gains from CPU pinning alone.

For PHP workloads, that latency hits opcode caches and in-memory data stores hard. Keeping workers and their memory together reduces cache misses and keeps p95 latency stable. Always check cache-miss and remote-memory counters when experimenting.

When Should You Consider Core Affinity For PHP Workers

Use the checklist below before touching any flags:

  • Long-lived workers? Yes: PHP-FPM pool. No: CGI or short-lived processes.
  • Host control? Yes: VPS/dedicated. No: pure shared hosting.
  • Symptoms? Noticeable CPU contention, p95/p99 spikes or cache-related slowdowns.
  • Hardware? Multi-socket NUMA server.

If most answers are “no,” first right-size PHP-FPM pools, improve opcode caching and add CDN layers. Affinity tuning is not a silver bullet.

Tools: taskset vs numactl – What Each Does and When To Use Which

taskset changes only CPU affinity. It tells the Linux scheduler which cores a process may run on and nothing more.

numactl, in contrast, can bind both CPU and memory to the same NUMA node, ensuring locality.

When to reach for each tool:

  1. taskset on single-socket or lightly loaded cores
    Example:taskset -cp 2,3 12345 # pin PID 12345 to cores 2 and 3Good for quick smoke tests where memory locality is irrelevant.
  2. numactl on multi-socket servers or memory-heavy workloadsnumactl –cpunodebind=0 –membind=0 php-fpmKeeps both CPU time and memory on NUMA node 0, protecting opcode cache locality.

Safety notes: taskset alone on a NUMA machine can increase remote-memory hits and hurt performance. Whichever tool you use, validate with numastat, per-core CPU load and cache-miss counters before and after.

Metrics to watch: p95 latency, per-core utilisation, numastat local vs remote, and hardware cache-miss counters.

Practical playbook: Conservative Core Affinity + NUMA Tuning for PHP-FPM on VPS/Dedicated

Below is a step-by-step, rollback-ready playbook.

  1. Preconditions and backups
    Verify you run PHP-FPM with long-lived children and have root or sudo. Snapshot config and schedule a maintenance window.
  2. Step 1 — Baseline
    Record throughput, p50/p95/p99 latencies, PHP-FPM pm.status, per-core CPU load, numastat, and cache-miss counts.
  3. Step 2 — Right-size PHP-FPM first
    Tune pm.max_children, pm.start_servers, and memory limits to avoid oversubscription. Re-benchmark.
  4. Step 3 — Lightweight taskset smoke test
    Pin the PHP-FPM master (and perhaps one child) to specific cores:taskset -cp 4,5 $(pgrep -o php-fpm)Run synthetic load; revert if latency worsens.
  5. Step 4 — NUMA-aware binding with numactlsystemctl edit php-fpm # ExecStart= /usr/bin/numactl –cpunodebind=1 –membind=1 /usr/sbin/php-fpm –nodaemonizeBenchmark again with real traffic. Compare against baseline for latency and numastat remote reads.
  6. Step 5 — Enforce via supervisor
    If gains persist, bake bindings into systemd or an init wrapper. Keep a commented fallback line for instant revert.
  7. Step 6 — Automate and document
    Commit wrapper scripts and systemd unit files to version control. Note pre/post metrics and screenshots for audit.

Safety checklist: ensure no core starvation (mpstat -P ALL), monitor scheduler latency, and respect other tenants if still on a shared node.

Safe Rollout Pattern and Measurement-first Monitoring Checklist

Adopt a canary-first mindset:

  • Canary strategy
    Apply affinity on a single node or 10 % of workers during off-peak hours. Use traffic splitting or A/B headers.
  • Metrics to collect
    Application: p50/p95/p99 latency, error rate, TTFB.
    Host: per-core CPU, steal time if virtualised, numastat local vs remote, cache-miss counters.
    PHP-FPM: active children, request duration, memory per worker.
  • Acceptance criteria
    No regression in p95/p99 latency or error rate, stable or higher throughput, reduced remote-memory access counts.
  • Automated rollback
    Keep one-line commands to drop affinity, reload PHP-FPM, or restore previous systemd units. Health checks can watch latency and auto-rollback if thresholds are breached.
  • Documentation
    Archive commands, config diffs, and metric dashboards before and after. Future you will thank present you.

When NOT to Tune Core Affinity on Shared Hosting and Safer Alternatives

Skip manual affinity if:

  • You lack root access, the server is heavily multi-tenant, or PHP runs as short-lived CGI.
  • The provider enforces its own scheduler policies that override pinning.

Safer wins:

  • Tweak PHP-FPM worker counts, optimise opcache and leverage full-page caching or a CDN.
  • If low-level control is essential, migrate to a managed VPS or dedicated plan. Vodien’s managed VPS line gives you admin access plus expert help for NUMA-aware tuning without the risk of going it alone.

    Also ReadHow to Run Python Flask on VPS Scalably

Platform-level NUMA-aware Scheduling (Enterprise Option, Brief Overview)

In containerised or VM fleets, NUMA-aware schedulers enforce CPU and memory locality automatically. You declare topology requests, and the orchestration layer keeps workloads on the correct node.

Benefits include consistent performance at scale and reduced human error, but adoption demands platform investment and is rarely available on commodity shared hosting.

Core Affinity for the Win

Core affinity pays off when workers live long, the hardware is multi-socket and you can keep memory local with numactl. Treat measurement as first class: baseline, canary, compare, then automate or roll back.

If tooling feels risky or you lack time, talk to Vodien’s support team about fully managed VPS tuning that brings NUMA-aware performance without the sleepless nights.