You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(server): respect CPU affinity and cgroup limits in shards and stats (#3615)
The server assumed it owned the whole host. Shards pinned to
absolute core ids 0..n, which fails with EINVAL (or lands on
forbidden cores) under systemd AllowedCPUs=, container cpusets,
or taskset. Stats reported host-wide CPU and memory, so a
confined instance showed its neighbors' load and a meaningless
host total.
Draw pinned cores from the process's allowed CPU set
(sched_getaffinity) instead, and validate configured ranges
against it at boot. A new pin_cores knob (default true) turns
pinning off for shared-core hosts (cgroup CPU quotas), where
every tenant pinning to the same low-numbered cores would pile
onto one core; unpinned shards let the kernel scheduler place
threads freely.
Stats now scope total_cpu_usage to the allowed cores and report
the effective cgroup memory limit as total_memory. Available
memory adds reclaimable file cache back
(limit - (current - inactive_file - active_file), minimum over
capped ancestors, v1 and v2), since memory.current charges page
cache as used and the naive limit - current trends to zero on a
cache-heavy server long before real OOM pressure.
"Invalid sharding configuration: cpu_allocation range {start}..{end} includes CPU {cpu}, which is outside the set of cores allowed for this process (affinity/cpuset mask)"
0 commit comments