一、进程状态

R状态：Running 正在运行或者Runnable等待运行，在cpu的就绪队列中

S状态：两种sleeping，一个可中断、一个不可中断（D状态，D就是vmstat的b那一列）

Z状态：父进程未回收子进程的资源，子进程变为僵尸状态

T状态：正在做什么，进程被暂停，例如正在运行top命令，然后按了ctrl+c

Linux进程转换

二、进程调度

背景：现在都是多任务、多进程的操作系统，多个进程（用户进程+系统进程）在操作系统中运行时，必然会存在这些进程要同时使用、并且争夺CPU资源，因此就要求有一个进程调度程序按一定的策略，动态地把cpu分配给处于就绪队列中的某一个进程，以使之执行。

1、调度：多个进程都在内存中，都需要运行，CPU现在处理A进程，一会儿再接管B进程，在A与B之间，或者C、D等进程不断重复接管、运行，就叫调度

2、调度程序：让CPU控制谁、接管谁

3、调度程序的功能：切换上下文

4、当cpu空闲，调度程序就要从内存中选择一个能够执行的进程，为其分配cpu

5、什么时候会发生调度？

分配到的CPU时间片用完了，进程会被挂起，轮流分配，被调度与进程优先级有关，进程会被挂起，被调度进程进入睡眠状态，进程会被挂起，被调度等待资源，资源不足，进程会被挂起，被调度

三、上下文切换context switch

3.1 什么是上下文

存储CPU正在执行的指令位置，下一条指令位置（寄存器、程序计数器）

3.2 什么是上下文切换

保存上一个任务进程的上下文到内核，加载新任务进程的上下文，且运行新任务，再次调度上一个任务，看起来是连续运行

cs就是上下文切换

3.3 上下文切换与性能的关系

切换次数多，cpu时间花费在保存上下文上面

3.4 上下文切换多少算高？

系统上下文切换次数趋势稳定【一般cs和in是相匹配的，in中断导致的cs上下文切换】，就没有问题出现突然增长，或者超过1万次以上，就要分析上下文切换多，出现的原因【一般都是应用进程本身的问题，出现问题的情况比较少】：

1）就是进程在等待资源，需要进一步监控内存、I/O

2）cpu本身的瓶颈

3）同时中断次数多，去分析中断处理程序，查看/proc/interrupts，cpu处理中断的分布，进一步分析中断的原因

注：中断in导致的上下文切换（查看/proc/interrupts，cpu处理中断的分布）、进程上下文切换、线程上下文切换（可以使用iotop，看哪个线程占用的io多，在dump对应的线程堆栈）

四、CPU总结

cpu监控的结论：

us、ni高：说明用户态进程占用了较多的cpu，所以应该着重排查进程的性能问题。【例如：应用程序的bug需要修复优化、kill掉无关进程、或nginx进程分配多核cpu这种设置，或将进程绑定到cpu，避免进程在多cpu上切换】

sy高：说明内核态进程占用了较多的CPU，所以应该着重排查内核线程或者系统调用的性能问题。

wa高：说明等待I/O的时间比较长，进一步监控IO使用率，繁忙程度，iotop，dstat，sar -d等。这个值不一定说明当前系统I/O出现问题，能导致CPU I/O wait 值升高，原因可能是：1）系统有未完成的IO正在处理，这个IO处理时间可能会比较长，但不一定说明磁盘IO到了瓶颈；2）进程因为等待IO完成而处于不可中断的睡眠状态，CPU此时是空闲状态

si高：说明软中断处理程序占用了较多的cpu，排查网络

hi高：应该着重排查内核中的中断服务程序，如：查看中断次数、中断的分配（/proc/interrupts）

cpu是否有瓶颈？

不能简单的看负载，也不能简单的看cpu占用

负载是否高，同时响应时间较慢，重启服务，仍然很快负载变高，响应时间变慢，多次重现，说明cpu是存在瓶颈的。

1、应用程序问题，导致CPU瓶颈

2、CPU本身资源不足，需要增加cpu资源

3、其他优化，例如设置nginx进程分配到多核CPU提升性能