Modern game servers rarely use every core you give them \u2014 most run their simulation on one or two threads while the rest of the box idles. On a shared or multi-instance machine, the OS scheduler can bounce those hot threads between cores, dragging cache and latency with them. CPU pinning (affinity) and NUMA awareness fix exactly that: they lock threads to specific cores and keep memory access local, which translates directly into steadier tick rates and lower worst-case ping. It is one of the cheapest performance upgrades available, because it costs nothing but configuration time.<\/p>\n\n\n\n
Skip pinning on a single-instance server with plenty of idle cores \u2014 the scheduler already keeps the hot thread resident, and you gain nothing but complexity. Pinning is a fix for contention, not a free speed boost.<\/p>\n\n\n\n
Before pinning anything, find out how cores and memory are laid out. On Linux:<\/p>\n\n\n\n
lscpu -e # core\/socket\/NUMA mapping per CPU\nlscpu | grep NUMA # NUMA node layout\ntaskset -pc $$ # current affinity of a shell<\/code><\/pre>\n\n\n\nA two-socket EPYC or Xeon box has two NUMA nodes, each with its own memory. Threads that run on node 0 but allocate memory on node 1 pay a cross-node penalty \u2014 small per access, but it adds up at thousands of ticks per minute. Single-socket machines have one node and none of these concerns, which is why many game hosts prefer them despite the lower core ceiling.<\/p>\n\n\n\n
Pinning with taskset and systemd<\/h2>\n\n\n\n
For a quick test, launch the server pinned to cores 0\u20131:<\/p>\n\n\n\n
taskset -c 0,1 .\/server.sh start<\/code><\/pre>\n\n\n\nFor something that survives reboots, use a systemd unit with CPUAffinity:<\/p>\n\n\n\n
[Service]\nExecStart=\/srv\/games\/minecraft\/start.sh\nCPUAffinity=0,1\nMemoryMax=8G<\/code><\/pre>\n\n\n\nOr pin by PID at runtime with taskset -p -c 0,1 $(pgrep -f java)<\/code>. To pin all threads of a multithreaded server, walk \/proc\/PID\/task\/*<\/code> and set affinity per thread \u2014 a short loop does it:<\/p>\n\n\n\nfor t in \/proc\/$(pgrep -f server)\/task\/*; do\n taskset -p -c 0,1 ${t##*\/}\ndone<\/code><\/pre>\n\n\n\nRemember that core numbers from lscpu -e<\/code> are physical IDs; on a hyperthreaded CPU, cores 0 and 1 may share a physical core. If you pin two busy instances to sibling threads, you get contention instead of isolation \u2014 check the CPU column of lscpu -e<\/code> and give each instance its own physical core.<\/p>\n\n\n\nNUMA-Aware Memory Placement<\/h2>\n\n\n\n
Pinning CPU without pinning memory gets you half the benefit. Use numactl<\/code> to keep the process’s memory on the same node as its cores:<\/p>\n\n\n\nnumactl --cpunodebind=0 --membind=0 .\/server.sh start<\/code><\/pre>\n\n\n\nOn a single-socket box there is one node, so this is a no-op \u2014 but on dual-socket hardware, membind prevents the “local CPU, remote RAM” pattern that shows up as erratic lag spikes. Check allocation with numastat -p PID<\/code> and \/proc\/PID\/numa_maps<\/code>. If the game allocates a huge world buffer at startup, keep it on the same node as the threads that touch it every tick.<\/p>\n\n\n\nRealistic Expectations<\/h2>\n\n\n\nScenario<\/th> Expected change<\/th><\/tr><\/thead> Two game servers on one box, cores split 4+4<\/td> Worst-case tick spikes drop 30\u201350%; average tick time unchanged<\/td><\/tr> Single server, idle box<\/td> No measurable difference<\/td><\/tr> Dual-socket, cross-node traffic eliminated<\/td> P99 latency improves; average latency roughly flat<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe pattern to notice: pinning smooths the tail, not the average. Your players will feel it as fewer lag spikes during raids and server-wide events, not as a lower baseline ping. That is exactly the profile a gaming community notices.<\/p>\n\n\n\n
Pitfalls to Avoid<\/h2>\n\n\n\n