Affinity процесса и vCPU pinning

Для обычного процесса affinity задает маску CPU, на которых планировщик может запускать поток. Маска действует только среди доступных и разрешенных системе CPU; cpuset/cgroup может дополнительно сузить набор.

В Linux дочерний процесс наследует affinity родителя, а sched_setaffinity ограничивается online CPU и правами. Фактический набор может быть уже маски из-за cpuset.

Affinity привязана к потоку. У многопоточного приложения проверьте worker-потоки и ограничения контейнера.

Affinity относится к потоку; у многопоточного приложения проверьте маску каждого worker и ограничения контейнера.

В libvirt элемент vcpupin сопоставляет конкретный vCPU виртуальной машины с физическими CPU хоста. Это другая настройка: она зависит от гипервизора, NUMA и параметров всей VM. В некоторых схемах отдельно закрепляют emulator threads и I/O threads.

Когда закрепление используют

Pinning применяют, чтобы управлять размещением чувствительной к задержкам нагрузки, разделять ресурсы или согласовать vCPU с NUMA topology. Но закрепленный процесс не получает эксклюзивное ядро автоматически; на нем могут работать другие потоки, если хост не выделил его отдельно.

Слишком узкая маска может ограничить параллелизм и вызвать очередь на одном CPU. Если меняется число vCPU, проверьте, что affinity не ссылается на отсутствующие или запрещенные ядра. Сравните задержки и загрузку до и после одинакового теста на собственном стенде.

Что уточнить у хостинга

В VPS клиент часто не видит физическую топологию хоста и не может самостоятельно задать vCPU pinning. Панель может показать только гостевые CPU, а гипервизор применяет свои правила. Не обещайте прогнозируемую производительность по одному числу vCPU.

Смотрите VPS/VDS, cgroups и KVM. Использованы Linux man-pages и документация libvirt, проверенные 8 октября 2026 года; CPU affinity и VM не менялись.