本文只是记录一个过程和思路，以供探讨。
现象
上午10点左右，用户报告某个服务器远程 jupyter 响应极慢。
登上服务器一看，用 htop 命令查看，可以看到：
- 内存 free 1.5TB，cache 600GB，已用 3TB
- CPU 256核心（超线程） 全部跑满。CPU 利用率 user 大概占 20%，sys 大概占 80%，idle 几乎为 0
- vmstat 显示大约有 5000+ 进程 runing，上下文切换每秒大概 1.7 亿次
粗略判断和解决
粗略判断 CPU 繁忙肯定是个问题，解决方案有两个：
- 降低大量占用 CPU 的程序优先级
- 将 jupyter 程序单独划分1，2个 CPU 核心，将其他计算密集型的程序划分到另外的 CPU
考虑到方案1比较容易操作，通过 ps axjf 把进程用树状列出来，找出耗费 CPU 的程序，然后结合 xargs 和 renice +19 调低其优先级。用户报告体验明显改善。同时 CPU 利用率基本上还是不变。
对现象的思考
然而，我对这里还有几个疑惑：
- 按 5000 个进程，256个 CPU 核心来算，那么每个核心大概分到20个进程。那么原先 jupyter 大概会分到二十分之一的计算资源。那么 renice 后能够分到多少资源，能够定量进行评估吗？我不确定 renice +19 应该起到多少作用。
- sys 占总量的 80%，这个是不是合理？应该占到多少才是合理的？和进程数量是有关系的吗？
- 上下文切换每秒为 17亿，是合理的吗？应该是多少？
对现象的分析
问题1的分析
经过讨论，我们发现还是得具体看代码。不大好评估具体影响。
问题3的分析
理论估算
我们看了一下 HZ 为 250，那么意味着每隔 4ms 就会有一次时间中断。
按照 CFS 的调度策略，我们可以认为每次时间中断会有一次调度，那么按 256 个核心，每隔核心每 4 ms发生一次调度来计算，每秒应该发生上下文切换数量为：256*1000ms/4ms = 6.4万 次。
我们写了一个小程序验证，在 128 核心，6000进程，计算密集型的情况下，上下文切换大概在3万左右，跟理论推断基本一致。
实际情况
上下文每秒切换 17亿次，那么意味着每个进程大概运行了 0.001ms 就会被换下来。预期应该是每个进程运行 4ms 才对。
问题2的分析
用 perf top 来进行分析，可以看到排名靠前的时间都花在上下文切换上：
分别为（switch_fpu_return, __switch_to_asm, load_new_mm_cr3）
对现象的推论和求证
推论
结合问题2和问题3，我们可以得出两个推论：
- sys 这么高很可能是上下文切换造成的
- 因为某些特别的情况，导致了一个很高的上下文切换
求证
通过对用户程序进行 strace 跟踪，我们可以观察到 futex 竞争的情况。经过网上搜索，我们推断可能是 futex 满足条件的时候，唤醒了太多的进程，从而导致了大量的颠簸。对此我们没有进一步的验证。
进一步的解决办法
考虑到实际上程序基本上都在上下文切换没干活，我们建议用户降低进程数量。
效果
在用户降低数量后，我们发现 CPU 的 user 占比大概达到了 60-80%，而sys则降低到了 2% 左右，同时空出了大量的 idle。考虑到用户的程序运行效率可以通过 user 的利用率来等价，因此我们可以推断用户的程序运行效率实际上提高了 3-4 倍。从用户程序运行的时间来看，也大概符合推断。
再进一步的评估
那么，对于这个效率，是否还能更高？是否符合预期？
从 CPU 结构的角度来看，256 核心实际上是开启了超线程后的结果，考虑到超线程的两个核心实际上共享了同一组计算单元，所以理论上来说能够达到 50% 左右的利用率，那么基本上就已经充分的利用了所有的计算资源了。
所以，我们预期这种情况下，实际上已经算是最好的结果了。因此也没有必要再继续进行调优了。
总结
- 要想办法解决用户的问题，用最简单的办法。以上用了 renice 来解决。
- 对于 sys 比较高的情况，要思考是否合理。即对这个值要有个概念，并且进行推测和证明。
- 对于最终结果，要进行验证和估计，看看是否已经优化到了预期值。
