紧接着之前的问题继续看：
系统负载 ： uptime top 看多个阶段平均负载
系统整体情况 ： mpstat （mpstat -p ALL 3） 查看 每个cpu当前的整体状况，可以重点看用户态、内核态、以及io等待三个参数
系统整体的平均上下文切换情况 ： vmstat (vmstat 3) 可以重点看 r （进行或等待进行的进程）、b （不可中断进程/io进程） 、in （中断次数） 、cs（上下文切换次数）
查看详细的上下文切换情况 ： pidstat （pidstat -w(进程切换指标)/-u（cpu使用指标）/-wt(线程上下文切换指标)） 注意看是自愿上下文切换、还是被动上下文切换
一次系统调用的过程，其实是发生了两次 CPU 上下文切换；但是系统调用的过程中并不会涉及虚拟内存等进程用户态的资源，一般不会切换进程，系统调用的过程通常称为特权模式切换，而不是上下文切换；
进程的切换只能发生在内核态，因此进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。
因此进程的上下文切换就比系统调用时多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。
保存上下文和恢复上下文的过程并不是免费的，需要内核在 CPU 上运行才能完成。据测试，每次上下文切换都需要几十纳秒到数微妙的 CPU 时间。特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间消耗在寄存器、内核栈、虚拟内存等资源的保存和恢复上，从而大大缩短了真正运行进程的时间
4、进程上下文何时切换
Linux 为每个 CPU 维护了一个就绪队列，将活跃进程按照优先级和等待 CPU 的时间排序，然后选择最需要 CPU 的进程，也就是优先级最高和等待 CPU 时间最长的进程来运行。那么，进程在什么时候才会被调度到 CPU 上运行呢？
- 进程执行完终止了，它之前使用的 CPU 会释放出来，这时再从就绪队列中拿一个新的进程来运行
- 为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片被轮流分配给各个进程。当某个进程时间片耗尽了就会被系统挂起，切换到其它等待 CPU 的进程运行。
- 进程在系统资源不足时，要等待资源满足后才可以运行，这时进程也会被挂起，并由系统调度其它进程运行。
- 当进程通过睡眠函数 sleep 主动挂起时，也会重新调度。
- 当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。
- 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。
copyfrom： https://www.linuxblogs.cn/articles/18120200.html 不知道是不是对的
- 自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如，IO、内存等系统资源不足时，就会发生自愿上下文切换。
- 非资源上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在抢占 CPU 时，就容易发生非自愿上下文切换。
先记录一下cpu结果：
pidstat -wt 1 全局结果发现：ksoft 以及 watchdog 也比较高
由于是16核： r等待队列为20+， 其上下文切换比较多
软中断budget调整：
net.core.netdev_budget = 300
netdev_budget: 这个的意思说的是，ksoftirqd一次最多处理300个包，处理够了就会把CPU主动让出来
目前为了提高内核收包效率，所以就把netdev_budget 提高一点设置为600 试一下：
貌似没用
软中断GRO合并：
http 中data是大文件的传输，大部分包都是一段数据，不用GRO的话，会每次都将一个小包传送到协议栈（IP接收函数、TCP接收）函数中进行处理。
开启GRO的话，Linux就会智能进行包的合并，之后将一个大包传给协议处理函数。这样CPU的效率也是就提高了？？
目前看不到 怎样优化 si 这部分协议栈处理了，估计也就是使用dpdk 来处理吧