有一个具有两道作业的批处理系统,作业调度采用短作业优先调度算法,进程调度采用以优先数为基础的抢占式

有一个具有两道作业的批处理系统,作业调度采用短作业优先调度算法,进程调度采用以优先数为基础的抢占式,第1张

本题中的系统是两道作业系统,因此每次只能有两个作业进入系统,作业调度

用短作业优先算法,只有调度进入系统的进程方能参与进程调度;进程调度采用

基于优先数的抢占式调度算法,高优先级的进程可以抢占系统处理机。

本题的作业和进程的推进过程如下:

10:00  A作业到达,被作业调度程序调度进入系统,被进程调度程序调度开始运行

10:20 A作业运行20分钟,剩余20分钟,由于优先级低,被进程调度程序调度处于就绪状态

B作业到达,被作业调度程序调度进入系统,由于优先级高,被进程调度程序调度处于开始运行状态

10:30 A作业等待10分钟,剩余20分钟,继续等待

B作业运行10分钟,剩余20分钟,继续运行

C作业到达,等待被作业调度程序调度

10:50 A作业等待30分钟,剩余20分钟,由于优先级高,被进程调度程序调度处于开始运行状态

B作业运行30分钟,作业完成,结束运行

C作业等待20分钟,由于估计运行时间较长,仍未被调入系统中运行

D作业到达,被进程调度程序调度处于就绪状态

11:10 A作业运行40分钟,作业完成,结束运行

C作业等待30分钟,被作业调度程序调度进入系统,由于优先级高,被进程调度程序调度处于开始运行状态

D作业等待10分钟,由于优先级低,被进程调度程序调度处于就绪状态

12:00 C作业运行50分钟,作业完成,结束运行

D作业等待70分钟,被进程调度程序调度处于开始运行状态

12:20 D作业运行20分钟,作业完成,结束运行

各作业周转时间为:

作业A  70,作业B  30,作业C  90,作业D  90。

平均作业周转时间为70分钟。

参考1.网页链接

2.网页链接

略改动。

 在进行Linux系统 *** 作的时候,有时候会遇到一次用户态进程死循环,即系统反应迟钝、进程挂死等问题,那么遇到这些问题又该如何解决呢?下面小编就给大家介绍下一次用户态进程死循环的问题该如何处理。

Linux下如何处理一次用户态进程死循环问题

1、问题现象

业务进程(用户态多线程程序)挂死, *** 作系统反应迟钝,系统日志没有任何异常。从进程的内核态堆栈看,看似所有线程都卡在了内核态的如下堆栈流程中:

[root@vmc116 ~]# cat /proc/27007/task/11825/stack

[《ffffffff8100baf6》] retint_careful+0x14/0x32

[《ffffffffffffffff》] 0xffffffffffffffff

2、问题分析

1)内核堆栈分析

从内核堆栈看,所有进程都阻塞在 retint_careful上,这个是中断返回过程中的流程,代码(汇编)如下:

entry_64.S

代码如下:

ret_from_intr:

DISABLE_INTERRUPTS(CLBR_NONE)

TRACE_IRQS_OFF

decl PER_CPU_VAR(irq_count)

/* Restore saved previous stack */

popq %rsi

CFI_DEF_CFA rsi,SS+8-RBP /* reg/off reset after def_cfa_expr */

leaq ARGOFFSET-RBP(%rsi), %rsp

CFI_DEF_CFA_REGISTER rsp

CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET

。。。

retint_careful:

CFI_RESTORE_STATE

bt $TIF_NEED_RESCHED,%edx

jnc retint_signal

TRACE_IRQS_ON

ENABLE_INTERRUPTS(CLBR_NONE)

pushq_cfi %rdi

SCHEDULE_USER

popq_cfi %rdi

GET_THREAD_INFO(%rcx)

DISABLE_INTERRUPTS(CLBR_NONE)

TRACE_IRQS_OFF

jmp retint_check

这其实是用户态进程在用户态被中断打断后,从中断返回的流程,结合retint_careful+0x14/0x32,进行反汇编,可以确认阻塞的点其实就在

SCHEDULE_USER

这其实就是调用schedule()进行调度,也就是说当进程走到中断返回的流程中时,发现需要调度(设置了TIF_NEED_RESCHED),于是在这里发生了调度。

有一个疑问:为什么在堆栈中看不到schedule()这一级的栈帧呢?

因为这里是汇编直接调用的,没有进行相关栈帧压栈和上下文保存 *** 作。

2)进行状态信息分析

从top命令结果看,相关线程实际一直处于R状态,CPU几乎完全耗尽,而且绝大部分都消耗在用户态:

[root@vmc116 ~]# top

top - 09:42:23 up 16 days, 2:21, 23 users, load average: 84.08, 84.30, 83.62

Tasks: 1037 total, 85 running, 952 sleeping, 0 stopped, 0 zombie

Cpu(s): 97.6%us, 2.2%sy, 0.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 32878852k total, 32315464k used, 563388k free, 374152k buffers

Swap: 35110904k total, 38644k used, 35072260k free, 28852536k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat

27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat

27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat

27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat

27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat

27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat

25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat

30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat

13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat

16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat

6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat

27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat

27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat

27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat

27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat

27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat

27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat

。。。

3)进程调度信息

从相关线程的调度信息看:

[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat

15681811525768 129628804592612 3557465

[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat

15682016493013 129630684625241 3557509

[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat

15682843570331 129638127548315 3557686

[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat

15683323640217 129642447477861 3557793

[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat

15683698477621 129645817640726 3557875

发现相关线程的调度统计一直在增加,说明相关线程一直是在被调度运行的,结合其状态也一直是R,推测很可能在用户态发生了死循环(或者非睡眠死锁)。

这里又有问题:为什么从top看每个线程的CPU占用率只有10%左右,而不是通常看到的死循环进程导致的100%的占用率?

因为线程数很多,而且优先级都一样,根据CFS调度算法,会平均分配时间片,不会让其中一个线程独占CPU。结果为多个线程间轮流调度,消耗掉了所有的cpu。。

另一个问题:为什么这种情况下,内核没有检测到softlockup?

因为业务进程的优先级不高,不会影响watchdog内核线程(最高优先级的实时线程)的调度,所以不会产生softlockup的情况。

再一个问题:为什么每次查看线程堆栈时,总是阻塞在retint_careful,而不是其它地方?

因为这里(中断返回的时候)正是调度的时机点,在其它时间点不能发生调度(不考虑其它情况~),而我们查看线程堆栈的行为,也必须依赖于进程调度,所以我们每次查看堆栈时,正是查看堆栈的进程(cat命令)得到调度的时候,这时正是中断返回的时候,所以正好看到的阻塞点为retint_careful。

4)用户态分析

从上面的分析看,推测应该是用户态发生了死锁。

用户态确认方法:

部署debug信息,然后gdb attach相关进程,确认堆栈,并结合代码逻辑分析。

最终确认该问题确为用户态进程中产生了死循环。

Linux进程调度

1.调度方式

Linux系统的调度方式基本上采用“ 抢占式优先级 ”方式,当进程在用户模式下运行时,不管它是否自愿,核心在一定条件下(如该进程的时间片用完或等待I/O)可以暂时中止其运行,而调度其他进程运行。一旦进程切换到内核模式下运行时,就不受以上限制,而一直运行下去,仅在重新回到用户模式之前才会发生进程调度。

Linux系统中的调度基本上继承了UNIX系统的 以优先级为基础 的调度。也就是说,核心为系统中每个进程计算出一个优先级,该优先级反映了一个进程获得CPU使用权的资格,即高优先级的进程优先得到运行。核心从进程就绪队列中挑选一个优先级最高的进程,为其分配一个CPU时间片,令其投入运行。在运行过程中,当前进程的优先级随时间递减,这样就实现了“负反馈”作用,即经过一段时间之后,原来级别较低的进程就相对“提升”了级别,从而有机会得到运行。当所有进程的优先级都变为0(最低)时,就重新计算一次所有进程的优先级。

2.调度策略

Linux系统针对不同类别的进程提供了3种不同的调度策略,即SCHED_FIFO、SCHED_RR及SCHED_OTHER。其中,SCHED_FIFO适合于 短实时进程 ,它们对时间性要求比较强,而每次运行所需的时间比较短。一旦这种进程被调度且开始运行,就一直运行到自愿让出CPU或被优先级更高的进程抢占其执行权为止。

SCHED_RR对应“时间片轮转法”,适合于每次运行需要 较长时间的实时进程 。一个运行进程分配一个时间片(200 ms),当时间片用完后,CPU被另外进程抢占,而该进程被送回相同优先级队列的末尾,核心动态调整用户态进程的优先级。这样,一个进程从创建到完成任务后终止,需要经历多次反馈循环。当进程再次被调度运行时,它就从上次断点处开始继续执行。

SCHED_OTHER是传统的UNIX调度策略,适合于交互式的 分时进程 。这类进程的优先级取决于两个因素:一个是进程剩余时间配额,如果进程用完了配给的时间,则相应优先级降到0;另一个是进程的优先数nice,这是从UNIX系统沿袭下来的方法,优先数越小,其优先级越高。nice的取值范围是-20 19。用户可以利用nice命令设定进程的nice值。但一般用户只能设定正值,从而主动降低其优先级;只有特权用户才能把nice的值设置为负数。进程的优先级就是以上二者之和。

后台命令对应后台进程(又称后台作业)。后台进程的优先级低于任何交互(前台)进程的优先级。所以,只有当系统中当前不存在可运行的交互进程时,才调度后台进程运行。后台进程往往按批处理方式调度运行。

3.调度时机

核心进行进程调度的时机有以下5种情况:

(1)当前进程调用系统调用nanosleep( )或者pause( ),使自己进入睡眠状态,主动让出一段时间的CPU的使用权。

(2)进程终止,永久地放弃对CPU的使用。

(3)在时钟中断处理程序执行过程中,发现当前进程连续运行的时间过长。

(4)当唤醒一个睡眠进程时,发现被唤醒的进程比当前进程更有资格运行。

(5)一个进程通过执行系统调用来改变调度策略或者降低自身的优先级(如nice命令),从而引起立即调度。

4.调度算法

进程调度的算法应该比较简单,以便减少频繁调度时的系统开销。Linux执行进程调度时,首先查找所有在就绪队列中的进程,从中选出优先级最高且在内存的一个进程。如果队列中有实时进程,那么实时进程将优先运行。如果最需要运行的进程不是当前进程,那么当前进程就被挂起,并且保存它的现场—— 所涉及的一切机器状态,包括程序计数器和CPU寄存器等,然后为选中的进程恢复运行现场。

(二)Linux常用调度命令

· nohup命令

nohup命令的功能是以忽略挂起和退出的方式执行指定的命令。其命令格式是:

nohup command [arguments]

其中,command是所要执行的命令,arguments是指定命令的参数。

nohup命令告诉系统,command所代表的命令在执行过程中不受任何结束运行的信号(hangup和quit)的影响。例如,

$ nohup find / -name exam.txt -print>f1 &

find命令在后台运行。在用户注销后,它会继续运行:从根目录开始,查找名字是exam.txt的文件,结果被定向到文件f1中。

如果用户没有对输出进行重定向,则输出被附加到当前目录的nohup.out文件中。如果用户在当前目录中不具备写权限,则输出被定向到$HOME/nohup.out 中。

· at命令

at命令允许指定命令执行的时间。at命令的常用形式是:

at time command

其中,time是指定命令command在将来执行时的时间和日期。时间的指定方法有多种,用户可以使用绝对时间,也可以用相对时间。该指定命令将以作业形式在后台运行。例如:

$ at 15:00 Oct 20

回车后进入接收方式,接着键入以下命令:

mail -s "Happy Birthday!" liuzheny

按下D键,屏幕显示:

job 862960800.a at Wed Oct 20 15:00:00 CST 1999

$

表明建立了一个作业,其作业ID号是862960800.a,运行作业的时间是1999年10月20日下午3:00,给liuzheny发一条标题为“Happy Birthday!”(生日快乐)的空白邮件。

利用 at -l 可以列出当前at队列中所有的作业。

利用 at -r 可以删除指定的作业。这些作业以前由at或batch命令调度。例如,

at -r 862960797.a

将删除作业ID号是862960797.a的作业。其一般使用形式是:

at -r job_id

注意,结尾是.a的作业ID号,表示这个作业是由at命令提交的;结尾是.b的作业ID号,表示这个作业是由batch命令提交的。

· batch命令

batch命令不带任何参数,它提交的作业的优先级比at命令提交的作业的优先级低。batch无法指定作业运行的时间。实际运行时间要看系统中已经提交的作业数量。如果系统中优先级较高的作业比较多,那么,batch提交的作业则需要等待;如果系统空闲,则运行batch提交的作业。例如,

$ batch

回车后进入接收方式,接着键入命令:

find / -name exam.txt -print

按下D。退出接收方式,屏幕显示:

job 862961540.b at Thu Nov 18 14:30:00 CST 1999

表示find命令被batch作为一个作业提交给系统,作业ID号是862961540.b。如果系统当前空闲,这个作业被立即执行,其结果同样作为邮件发送给用户。

· jobs命令

jobs命令用来显示当前shell下正在运行哪些作业(即后台作业)。例如:

$ jobs

[2] + Running tar tv3 *&

[1] - Running find / -name README -print >logfile &

$

其中,第一列方括号中的数字表示作业序号,它是由当前运行的shell分配的,而不是由 *** 作系统统一分配的。在当前shell环境下,第一个后台作业的作业号为1,第二个作业的作业号为2,等等。

第二列中的“ ”号表示相应作业的优先级比“-”号对应作业的优先级高。

第三列表明作业状态,是否为运行、中断、等待输入或停止等。

最后列出的是创建当前这个作业所对应的命令行。

利用 jobs -l 形式,可以在作业号后显示出相应进程的PID。如果想只显示相应进程的PID,不显示其它信息,则使用 jobs -p 形式。

· fg命令

fg命令把指定的后台作业移到前台。其使用格式是:

fg [job…]

其中,参数job是一个或多个进程的PID,或者是命令名称或者作业号(前面要带有一个“%”号)。例如:

$ jobs

[2] + Running tar tv3 *&

[1] - Running find / -name README -print >logfile&

$ fg %find

find / -name README -print >logfile

注意,显示的命令行末尾没有“&”符号。下面命令能产生同样的效果:

$ fg %1

这样,find命令对应的进程就在前台执行。当后台只有一个作业时,键入不带参数的fg命令,就能使相应进程移到前台。当有两个或更多的后台作业时,键入不带参数的fg,就把最后进入后台的进程首先移到前台。

· bg命令

bg命令可以把前台进程换到后台执行。其使用格式是:

bg [job…]

其中,job是一个或多个进程的PID、命令名称或者作业号,在参数前要带“%”号。例如,在cc(C编译命令)命令执行过程中,按下Z键,使这个作业挂起。然后键入以下命令:

$ bg %cc

该挂起的作业在后台重新开始执行。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/7505845.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-06
下一篇 2023-04-06

发表评论

登录后才能评论

评论列表(0条)

保存