TL;DR：在多核服务器上，CPU 占用大的进程共享核心，而其他核心则处于空闲状态，而我期望 Linux 调度程序能够在核心之间均匀分配作业。什么可能导致此行为？
我的工作组有一台运行 SuSE 的新 4 核服务器，它遇到了一些奇怪的 CPU 调度行为，我们的管理员（设置该服务器的人）对此并不知情，似乎无法修复。我希望大家能帮助我诊断可能导致这种奇怪行为的原因。以下是症状：
1) 每个 SSH 会话似乎都只能使用一个核心。我测试过各种方法，但最简单的方法是创建一个简单的无限循环 C 程序并运行多个副本。如果从单个 SSH 会话启动，它们总是共享一个核心，我甚至无法控制哪个核心；它似乎是在登录时设置的。此外，即使使用多个同时进行的 SSH 会话，我以这种方式唯一可以利用的核心是核心 0 和 3；无论我启动多少个会话或进程，1 和 2 都不会被触及。
2) 如果从上述 SSH 会话中，我使用“nohup”启动程序以将其与当前会话分离，它将使用与从该会话启动的其余程序不同的核心。但是，来自同一 SSH 会话的所有 nohup 启动的程序将再次彼此共享一个核心。有趣的是，这些 nohup 启动的程序始终分配给核心 1 和 2。
当然，预期的行为是我在其他 Linux 系统上一直看到的（我最熟悉的是 RHEL、Fedora 和 Ubuntu）：我应该能够在单个会话中使用所有 4 个核心，无论是否使用 nohup；此外，作业应该偶尔跳过核心以平衡它们之间的加载时间。
以下是在一个核心上运行两个进程的示例：https://i.stack.imgur.com/BRmY9.png（抱歉，目前还不能直接发布图片，尽管我在其他 StackExchange 网站上已经获得了足够的信任）。请注意，如果单独运行，每个“burn”进程都会占用一个核心的 100%，但在这里，由于某种原因，它们共享一个核心，而三个核心处于空闲状态。还请注意，这两个进程共享“Cpu3”核心超过 20 分钟，而没有切换到另一个核心来平衡负载（这是在拍摄图像之后；20 分钟后我停止观看）。
遇到此问题时，我的第一个想法是“ulimit”有效，但以我（非专家）的眼光来看，情况并非如此：
dmonner@bass:~> ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128465
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 13988192
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 128465
virtual memory (kbytes, -v) 40007280
file locks (-x) unlimited
此外，/etc/security/limits.conf 是空的（或者至少没有非注释的行），所以我不认为这是 PAM 强制限制。
我在机器上具有 sudo 访问权限，即使我“sudo su”然后运行进程，我也会以同样的方式受到核心限制。
那么：有人知道是什么原因导致了这种行为，以及如何摆脱它吗？
答案1
Linux 调度程序（如果应用程序不自行执行）永远不会将任何内容绑定到任何特定核心。事实上恰恰相反，大多数时候，调度程序会以看似随机的方式在所有核心之间转移负载。它是内核中唯一具有系统整体视图的部分，它试图根据一些启发式方法“优化”系统响应/吞吐量，这表现为内核在核心之间转移进程。
您必须通过类似方法明确将进程固定到特定核心才能taskset(1)实现此目的。您能提供一些证据来说明您遇到的情况吗？