本篇内容介绍了“linux进程D状态的原理是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
简单来讲
1)内核每隔一段时间都会统一接受所有进程的请求(这里可能与CPU时间片有关系,需要进一步确认),如果发现有进程发起了请求,首先内核会去获取进程所需要的资源,然后把这个进程暂时放到一个停车队列里;这里类似于需求收集阶段。
2)在需求收集结束后,会把发起请求的进程放到一个可运行队列里,等待执行。
3)把runnable队列里的进程依次执行。
进程的D状态(不间断睡眠)发生在需求收集阶段。试想在这个阶段,当内核去获取进程所需要的资源的时候,比如从磁盘读取某一个文件,这个时候突然磁盘驱动不干活了(可能因为取的数据太多驱动没反应过来,也可能因为磁盘出了故障),这个时候内核就为难了,场面变得比较尴尬。
1)首先驱动是工作在内核态的,内核对驱动有绝对的信任权;其次,
2)进程发起请求了,自己作为老大于情于理都应该应承;
3)但是进程所要求的数据实在拿不到怎么办呢?
4)这个时候内核只能把进程的状态临时转换为D状态,标明这个锅是内核自己的,内核正在尝试获取进程需要的资源,而且获取资源的途径是内核可控的(内核必须对全局的资源拥有控制权限,否则也不要当内核了)。
上面的情况,如果进程所需要的数据很快就被内核拿到了还好(大部分情况下都是如此),进程会从D状态转到可运行的状态,如果拿不到(比如真的磁盘出现了故障,而驱动代码又没有考虑到这种情况,或者驱动抛出了信号但是内核不承认),那么相应的进程就会一直处于D状态。非常戏剧性的是,只有处于可运行状态(runnable)的进程可以接受终止信号(杀信号),处于D状态的进程是没有办法被消磨掉的,这也让终止D状态的进程变得复杂,必须重启服务器才能把D状态的进程杀掉……不过想一想也好理解,因为流程卡在内核那里,这个时候内核与进程是绑定的状态,内核限制进程不接受被杀死的信号也是理所当然的(我的理解是,这里的内核过于自信了,我的故障机是4.4.0内核版本,或许高版本的已经没有这个问题了)。
参考:
https://jingwei.link/2018/12/23/linux-cpu-load-d-process。html
