实时优先级范围是0到MAX_RT_PRIO-1（即99），而普通进程的静态优先级范围是从MAX_RT_PRIO到MAX_PRIO-1（即100到139）。值越大静态优先级越低。
这两天在研究docker容器的底层原理和k8是相关的一些东西，说实话，这块儿的内容还挺复杂的，尤其是k8s的集群运维方面，没有一点沉淀真的很难理解各种模块之间的关系，我目前也是在摸索阶段。
很多时候，我们要监控系统状态，即监控系统cpu负载、进程状态等情况，如果我们在 Linux 应用层，我们有很多方式，命令行中常用 top、ps 命令，代码中，我们可以使用 popen 函数去执行一个 top 命令，获取返回值。或者我们直接读写 /proc下面的文件，都可以达到目的。
2014-03-20 21:45:45 Full thread dump OpenJDK (Taobao) 64-Bit Server VM (20.0-b12-internal mixed mode):
CPU 过高、Full GC次数过多、内存使用过多、硬盘空间不足等问题，都会带来系统突然运行缓慢的问题，也是面试特别容易被问到的，下面针对系统运行缓慢等问题进行展开。
如果大家有过在容器中执行 ps 命令的经验，都会知道在容器中的进程的 pid 一般是比较小的。例如下面我的这个例子。
背景：最近在梳理Android线程调度的相关内容。在梳理过程中，阅读了部分源码，以及相关的介绍文章，甚至重新翻起了《Linux内核设计与实现》，但是距离理解透彻，并且能够用自己的语言清晰无误地阐述出来，感觉还有点远，还有很多细节需要进一步理论结合实际。为了避免在忙乱的生活节奏中，梳理的目标又草草结束。希望自己能够把目标细分一下，先把几个理解清晰的问题给记录下来，通过不断清晰地回答相关的问题，最终能够完成整个原理的清晰理解与阐述。这篇文章，就是针对Android线程优先级方面，一个一个问题的回答，可能有些凌
中 , 简单介绍了 进程优先级概念 , 本篇博客中开始介绍 Linux 内核中优先级相关源码 ;
Linux Kernel Development 一书中，关于 Linux 的进程调度器并没有讲解的很全面，只是提到了 CFS 调度器的基本思想和一些实现细节；并没有 Linux 早期的调度器介绍，以及最近这些年新增的在内核源码树外维护的调度器思想。所以在经过一番搜寻后，看到了这篇论文 A complete guide to Linux process scheduling，对 Linux 的调度器历史进行了回顾，并且相对细致地讲解了 CFS 调度器。整体来说，虽然比较啰嗦，但是对于想要知道更多细节的我来说非常适合，所以就有了翻译它的冲动。当然，在学习过程也参考了其它论文。下面开启学习之旅吧，如有任何问题，欢迎指正~
Linux 中采用了两种不同的优先级范围，一种是 nice 值，一种是实时优先级。在上一篇粗略的说了一下 nice 值和实时优先级，仍有不少疑问，本文来详细说明一下进程优先级。linux 内核版本为 linux 2.6.34 。
从0~99的范围专供实时进程使用, nice的值[-20,19]则映射到范围100~139
计算机存在的目的就是为了运行各种各样的程序，迄今我们介绍的绝大多数命令，都是为了完成某种计算而用编程语言编写的程序，它们以文件的形式保存在操作系统之中(比如/bin下的各种命令)；但静态的程序并不能“自发的”产生结果，只有在操作系统中为其指定输入数据并运行起来，才能得到输出结果。而操作系统中程序运行的最主要表现形式便是进程。 静态程序可以长久的存在，动态的进程具有有限的生命周期。每次程序运行的开始(如键入一条命令后按下回车键)，操作系统都要为程序的运行准备各种资源，这些资源绝大多数都处于内存之中。为了限制多用户进程的权限，linux还定义了两种进程运行时态：内核态和用户态；当进程想要请求系统服务时(比如操作一个物理设备)，必须通过系统调用(操作系统提供给用户空间的接口函数)来实现，此时系统切换到内核态，代表程序执行该系统调用，执行完毕后系统切换回用户态，继续执行程序代码。 本文介绍linux中关于进程与内存的管理命令(更多的是查看命令)
如果你对 Linux 流控感兴趣，如果你需要搭建高性能的 Linux 网关 , 本文将会使你受益颇多。
接触过docker的同学多多少少听过这样一句话“docker容器通过linux namespace、cgroup特性实现资源的隔离与限制”。今天我们来尝试学习一下这两个东西。
监视虚拟机各种运行状态信息;显示进程中的 类加载、内存、垃圾收集、即时编译 等; 如果没有GUI图形化界面的服务器,可以通过该命令查看运行状况,命令格式:
温馨提示，动图已压缩，流量党放心查看。CPU方面内容不多，我们顺便学点命令。本篇是《荒岛余生》系列第二篇，垂直观测CPU。其余参见：
负荷权重用struct load_weight数据结构来表示, 保存着进程权重值weight。其定义在/include/linux/sched.h, v=4.6, L1195, 如下所示
调度器面对的情形就是这样, 其任务是在程序之间共享CPU时间, 创造并行执行的错觉, 该任务分为两个不同的部分, 其中一个涉及调度策略, 另外一个涉及上下文切换.
Linux 内核的 " 进程调度 " 是按照 设计好的调度算法 安排的 , 该算法对应的功能模块 称为 " 调度器 " , 英文名称是 Scheduler ;
CFS 调度器 ( Completely Fair Scheduler ) 是 " 完全公平调度器 " , " 完全公平调度算法 " 对每个 进程 都是 公平 的 ,
在 linux-5.6.18\include\linux\sched.h 头文件中 task_struct " 进程描述符 " 结构体 中定义了 进程优先级字段如下 :
参考 【Linux 内核】调度器 ⑨ ( Linux 内核调度策略 | SCHED_NORMAL 策略 | SCHED_FIFO 策略 | SCHED_NORMAL 策略 | SCHED_BATCH策略 ) 博客 , 介绍了 Linux 内核相关的调度策略 ;
进程提供了两种优先级，一种是普通的进程优先级，第二个是实时优先级。前者适用SCHED_NORMAL调度策略，后者可选SCHED_FIFO或SCHED_RR调度策略。任何时候，实时进程的优先级都高于普通进程，实时进程只会被更高级的实时进程抢占，同级实时进程之间是按照FIFO（一次机会做完）或者RR（多次轮转）规则调度的。 1.实时进程的调度 实时进程，只有静态优先级，因为内核不会再根据休眠等因素对其静态优先级做调整，其范围在0~MAX_RT_PRIO-1间。默认MAX_RT_PRIO配置为100，也即，
本篇主要讲述了利用tc工具对 Linux 进行高级流量控制.TC流量控制工具 , 从 Linux2.2 版开始已并入内核而且功能非常强大。如果你需要搭建高性能的 Linux 网关 , 本文将会使你受益颇多。
在项目中遇到一个问题，我们服务提供给外部的一个接口 queryXXX 一直返回 429 错误（Too Many Requests），接口没有返回值，而且服务越用越卡，要重启一下才能恢复。于是马上就想到是不是因为这个接口产生了死循环，导致接口无法正确返回，同时导致后台 CPU 和内存占用飙升，顺着这个思路定位下去，确实顺利的找到的问题所在。
在 Linux 内核 中 , " 进程控制块 " 是通过 task_struct 结构体 进行描述的 ; Linux 内核中 , 所有 进程管理 相关算法逻辑 , 都是基于 task_struct 结构体的 ;
查看java程序运行的环境参数，包括Java System属性和JVM命令行参数.。
使用top命令查看资源占用情况，发现pid为14063的进程占用了大量的CPU资源，CPU占用率高达776.1%，内存占用率也达到了29.8%
Busybox在单一的可执行文件中提供了精简的Unix工具集，可运行于多款POSIX环境的操作系统，例如Linux（包括Android）、Hurd、FreeBSD等等。
首先可以通过ps命令找到进程id，比如 ps -ef | grep kafka 可以看到kafka这个程序的进程id
swap space 是磁盘上的一块区域，当系统物理内存吃紧时，Linux 会将内存中不常访问的数据保存到 swap 上，这样系统就有更多的物理内存为各个进程服务，而当系统需要访问 swap 上存储的内容时，再将 swap 上的数据加载到内存中，这就是常说的换出和换入。交换空间可以在一定程度上缓解内存不足的情况，但是它需要读写磁盘数据，所以性能不是很高。
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。
Linux内核中使用 task_struct 结构来表示一个进程，这个结构体保存了进程的所有信息，所以它非常庞大，在讲解Linux内核的进程管理，我们有必要先分析这个 task_struct 中的各项成员
O(n)调度器采用一个runqueue运行队列来管理所有可运行的进程，在主调度schedule函数中会选择一个优先级最高，也就是时间片最大的进程来运行，同时也会对喜欢睡眠的进程做一些补偿，去增加此类进程的时间片。当runqueue运行队列中无进程可选择时，则会对系统中所有的进程进行一次重新计算时间片的操作，同时也会对剩余时间片的进程做一次补偿。
一、在前面介绍了system v 消息队列的相关知识，现在来稍微看看posix 消息队列。 posix消息队列的一个可能实现如下图： 其实消息队列就是一个可以让进程间交换数据的场所，而两个标准的消息队
Linux是一个支持多任务的操作系统，而多个任务之间的切换是通过 调度器 来完成，调度器 使用不同的调度算法会有不同的效果。
在内核中，肯定不能对所有的进程一视同仁，有的进程需要优先运行，有的进程需要运行更长的时间
但凡懂Linux内核的，都知道Linux内核的CFS进程调度算法，无论是从2.6.23将其初引入时的论文，还是各类源码分析，文章，以及Linux内核专门的图书，都给人这样一种感觉，即 CFS调度器是革命性的，它将彻底改变进程调度算法。 预期中，人们期待它会带来令人惊艳的效果。
程序里少不了运算，如果不是环境太恶劣，CPU基本是能支撑应用运行的。但如果发现CPU居高不下，就需要思考是否程序有问题。 当服务器CPU居高不下，可以从下面几个方面入手定位问题。 找到JAVA进程 pid 方法一: jps 那个jar就是我的一个java程序 [root@iZba13i1mo82ot7a3lhq5oZ ~]# jps 17616 Jps 26016 jar 9353 Bootstrap 26028 Bootstrap 16812 Bootstrap 方法二: ps -ef|grep 应用关键
(1)任务可以是一个无限的循环，也可以在一次执行完毕后被删除。 这里需要注意的是，任务的代码并不是真正的删除了，而是UCOSII不再理会该任务代码，所以该任务代码不会再执行。
「 不加思考地滥读或无休止地读书,所读过的东西无法刻骨铭心,其大部分终将消失殆尽。——叔本华」
前言 cgroup作为Linux上广泛应用的一个功能，用来限制、控制与分离一个进程组群的资源。在内核Linux-4.14上，支持了如下类型（源代码参考https://github.com/torvalds/linux/blob/v4.14/include/linux/cgroup_subsys.h）： SUBSYS(cpuset) SUBSYS(cpu) SUBSYS(cpuacct) SUBSYS(io) SUBSYS(memory) SUBSYS(devices) SUBSYS(freezer) SUBSYS(net_cls) SUBSYS(perf_event) SUBSYS(net_prio) SUBSYS(hugetlb) SUBSYS(pids) SUBSYS(rdma) SUBSYS(debug) 查看目前实际打开了其中的一部分： # cat /boot/config-`uname -r` | grep CONFIG_CGROUP_ CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_CGROUP_PIDS=y # CONFIG_CGROUP_RDMA is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NET_PRIO=y CONFIG_CGROUP_NET_CLASSID=y 尤其是其中的CPU的Quota控制，在以docker为代表的PaaS中大显身手。然而，这并不意味着cgroup的CPU Quota控制就是完美的。例如，希望一个进程占用的CPU不超过200%，那么它的真实的CPU占用是怎样的呢？接下来，作者会构造一段代码，可以算是一种极端场景，来证实这个问题确实存在。
The normal way to put a process to sleep is to set the process's state to either TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE and call the scheduler's function schedule(). This results in the process getting moved off from the CPU run queue. If the process is sleeping in interruptible mode (by setting its state to TASK_INTERRUPTIBLE), it can be awakened either by an explicit wake-up call (wakeup_process()) or by signals needing processing.
内核采用“插桩”的方法抓取log，“插桩”也称为Tracepoint，Tracepoint是Linux内核预先定义的静态探测点，它分布于内核的各个子系统中，每种Tracepoint有一个name、一个enable开关、一系列桩函数、注册桩函数的函数、卸载桩函数的函数。“桩函数”功能类似于printk，不过“桩函数”并不会把信息打印到console，而是输出到内核的ring buffer（环形缓冲区），缓冲区中的信息通过debugfs对用户呈现。每个tracepoint提供一个钩子来调用probe函数。一个tracepoint可以打开或关闭。打开时，probe函数关联到tracepoint；关闭时，probe函数不关联到tracepoint。tracepoint关闭时对kernel产生的影响很小，只是增加了极少的时间开销(一个分支条件判断)，极小的空间开销(一条函数调用语句和几个数据结构)。只有挂载了钩子函数才会真正启用trace功能。这个钩子函数可以由开发者编写内核module来实现，并且需要在钩子函数中获取我们调试所需要的信息并导出到用户态，这样就可以获取内核运行时的信息了。当一个tracepoint打开时，用户提供的probe函数在每次这个tracepoint执行都会被调用。
种类型 , " 限期进程 " , " 实时进程 " , " 普通进程 " ; 从 " 进程优先级 " 角度对比 , 优先级从高到低分别是 : 限期进程 > 实时进程 > 普通进程 ;
在 【Linux 内核】实时调度类 ② ( 实时调度实体 sched_rt_entity 源码分析 | run_list、timeout、watchdog_stamp、time_slice 字段 ) 博客中 , 简单介绍了 在 linux-5.6.18\include\linux\sched.h 头文件中定义的 实时调度实体 sched_rt_entity 源码 ,
不加思考地滥读或无休止地读书,所读过的东西无法刻骨铭心,其大部分终将消失殆尽。——叔本华
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
