linux查看线程优先级命令_系统运维

用top或者ps -l查看进程会发现有PR(PRI) NI两个字段：NI 是优先值，是用户层面的概念， PR是进程的实际优先级，是给内核（kernel）看（用）的。一般情况下，PR=NI+20, 如果一个进程的优先级PR是20，那么它的NI(nice)值就是20-20=0。进程调度优先级是从-20到19，一共40个级别，数字越大，表示进程的优先级越低。默认时候，进程的优先级是0。查看进程优先级有两个办法：ps和top。top命令显示的NI列的值。或者可以使用ps -efl来查看，也是在ni列表示了进程的优先级。《Linux就该这么学》一起学习，进程的优先级可以在程序运行的时候设置，也可以在程序运行过程中动态的修改。

主要参考 ：Linux manual page - sched

自从linux内核2.6.23以来，默认的进程调度器就被设置为完全公平调度器（CFS，complete fair scheduler），取代了之前的O(1)调度器。

每个线程都有一个静态调度优先级，即 sched_priority 字段。

一个线程的调度策略决定了线程会被插入到同级静态优先级的线程队列的位置，以及它在队列中会怎样移动。

所有的调度都是可插入的，如果一个更高静态优先级的线程准备好了，现在运行中的线程就会被插入。而调度策略则仅仅影响了同样静态优先级的线程。

进程（线程）可以通过系统调用设置自身或者其他进程（线程）的调度策略。

其中 pid 为0时，设置自身的调度策略和参数。结构体 sched_attr 包含以下字段： size 、 sched_policy （即调度策略，具体会在下一节介绍）、 sched_flags 、 sched_nice 、 sched_runtime 、 sched_deadline 、 sched_period （最后三个为 SCHED_DEADLINE 相关的参数）。当设置成功，系统调用返回0；否则返回-1，并会设置 errno 。

普通进程： SCHED_OTHER / SCHED_BATCH / SCHED_IDLE

实时进程： SCHED_FIFO / SCHED_RR

特殊实时进程： SCHED_DEADLINE

静态优先级：Static_priority：对于普通进程，静态优先级为0；对于实时进程，静态优先级为1-99，99为最高优先级。

动态优先级：Dynamic_priority：仅对普通进程有用，取决于nice和一个动态调整的量（比如进程ready却没被调度，则增加）。

　在进行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）进程调度信息

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