On modern AMD and Intel server CPUs, core numbering is not flat. AMD EPYC and Ryzen parts split into Core Complex Dies (CCDs), each with its own L3 cache slice and memory path; Intel split-core designs do something similar with their ring and tile topology. A game server process that spreads its threads across two CCDs pays an inter-CCD latency penalty on every shared-memory access. On a Minecraft or Valheim node, that penalty shows up directly as lost TPS. This article shows how to detect it and fix it with thread pinning.<\/p>\n\n
A game simulation loop touches hot data structures thousands of times per second: entity maps, chunk arrays, player state. When those structures fit inside one L3 slice (typically 32 MB per CCD on recent EPYC), the loop runs from cache. When two threads owning the same data structure run on different CCDs, every cross-thread access traverses the Infinity Fabric or mesh at 40-80 ns instead of 10-15 ns. Multiplied across a 20-tick loop with thousands of entity updates, the effect is a measurable drop in achievable tick rate.<\/p>\n\n
Linux exposes the cache topology through sysfs. Run these commands on your node to map which cores share an L3 slice:<\/p>\n\n
lscpu -e=CPU,CORE,SOCKET,NODE,CACHE<\/code> shows logical layout and NUMA nodes.<\/li>cat \/sys\/devices\/system\/cpu\/cpu0\/cache\/index3\/shared_cpu_list<\/code> lists cores sharing that L3 slice.<\/li>lstopo --of txt<\/code> (from hwloc) prints a readable tree of packages, CCDs, and caches.<\/li>numastat -p <pid><\/code> reveals NUMA misses for a running server process.<\/li><\/ul>\n\nIf the JVM or game binary shows a thread group split across two different shared_cpu_list<\/code> ranges, you have a locality problem.<\/p>\n\nThe Fix: Pin the Sim Thread to One CCD<\/h2>\n\n
The primary simulation thread and its GC or allocator threads should live on cores inside a single CCD. On a typical EPYC 8-core-per-CCD layout, that means pinning to cores 0-7 rather than letting the scheduler roam across 0-15. For a single instance, restrict the process to one CCD:<\/p>\n\n
taskset -c 0-7 java -jar server.jar<\/code> binds the process to the first CCD.<\/li>- In systemd, set
CPUAffinity=0-7<\/code> in the unit file.<\/li>- For containers, use
cpuset.cpus=0-7<\/code> in the cgroup.<\/li>- Match NUMA memory with
numactl --cpunodebind=0 --membind=0<\/code>.<\/li><\/ul>\n\nMulti-Instance Placement Strategy<\/h2>\n\n
When you host several game instances on one machine, assign each instance its own CCD rather than interleaving them. Two Minecraft worlds each pinned to separate 8-core CCDs will outperform the same two worlds spread randomly across 16 cores, because neither instance evicts the other’s hot working set. This is the practical argument for owning a machine with many CCDs when you run a multi-game community.<\/p>\n\n