为了正确调整 Linux 主机的大小，了解待处理事项的积压情况非常重要。procs_running（特别是除以核心数量时）是进程积压的良好指标，但无法深入了解线程积压。就平均负载而言，一切看起来都很顺利，但基于挂起的线程可能会给 CPU 带来巨大的压力。例如，当单个进程侦听套接字并通过生成多个线程来处理多个套接字连接时，可能会发生这种情况，每个线程都会给 CPU 带来负载。在这种情况下，只有一个进程在运行，因此平均负载和 procs_running 较低，但 cpu 固定在 100%，客户端工作负载的延迟较高。
有什么方法可以深入了解此类线程队列的大小 - 即。正在等待 cpu 运行时的线程？
答案1
procs_running线程的等价物是procs_running它本身。它包含返回的值nr_running,这是正在运行的线程数。
（一般来说，就内核而言，线程就是进程。）
答案2
经过一番摸索，我基本上可以回答我自己的问题了。
-L包含ps进程的所有线程的选项。在我的主机上观察这一点，我注意到当客户端开始通过网络连接到我的服务时，procs_running 永远不会超过 4（每个核心 1 个），但与该进程关联的处于睡眠状态的线程数开始从 78 上升到140，并且在所有客户端完成其请求之前不会返回到 78。这大约需要一个小时，在此期间所有核心的利用率始终保持在 100%。平均负载永远不会超过 4。
因此，-L事实上，在这种特殊情况下，当您有一个服务于网络请求的进程时，该选项是一个很好的积压指标。在这种情况下，procs_running（也不是直接相关的负载平均）指示积压的大小。这是因为只有一个父进程根据连接的客户端数量派生出新线程，并且procs_running仅反映父进程的队列大小。
我唯一不明白的是为什么线程被标记为处于Sleep状态。我认为它们应该是可运行的，因为它们正在等待 cpu 时间。如果有人知道这个问题的答案，请告诉我。
正如我在问题中提到的，能够测量积压工作很重要的原因是为了调整实例大小。仅测量当前利用率是不够的。
编辑：这并不令人满意。通常情况下，您会期望每个线程为积压工作 (procs_running) 贡献 1，但这不是这里发生的情况。我唯一可以得出的结论是，应用程序在内部做自己的事情，比如在自己的线程上发出 sleeps() 。除了已建立的套接字数量之外，我看不到操作系统有任何方法可以了解待处理的积压工作。
顺便说一句，有问题的应用程序是 puppetserver。