2020-05-23 TalkGo 读书会第一期「Linux 性能优化实战」【2020.05.25~2020.07.25】【入群私享】

第一周总结笔记

平均负载是指单位时间内,系统处于 可运行状态不可中断状态 的平均进程数,也就是 平均活跃进程数。

不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

CPU 上下文切换,就是先把前一个任务的 CPU 上下文(也就是 CPU 寄存器和程序计数器)保存起来,然后加载新任务的上下文到这些寄存器和程序计数器,最后再跳转到程序计数器所指的新位置,运行新任务。

根据任务的不同,CPU 的上下文切换就可以分为几个不同的场景,也就是 进程上下文切换线程上下文切换 以及 中断上下文切换

进程上下文切换

Linux 按照特权等级,把进程的运行空间分为内核空间和用户空间,分别对应着下图中, CPU 特权等级的 Ring 0 和 Ring 3。

  • 内核空间(Ring 0)具有最高权限,可以直接访问所有资源;

  • 用户空间(Ring 3)只能访问受限资源,不能直接访问内存等硬件设备,必须通过系统调用陷入到内核中,才能访问这些特权资源。

image.png

换个角度看,也就是说,进程既可以在用户空间运行,又可以在内核空间中运行。进程在用户空间运行时,被称为进程的用户态,而陷入内核空间的时候,被称为进程的内核态。

进程是由内核来管理和调度的,进程的切换只能发生在内核态。

其一,为了保证所有进程可以得到公平调度,CPU 时间被划分为一段段的时间片,这些时间片再被轮流分配给各个进程。这样,当某个进程的时间片耗尽了,就会被系统挂起,切换到其它正在等待 CPU 的进程运行。

其二,进程在系统资源不足(比如内存不足)时,要等到资源满足后才可以运行,这个时候进程也会被挂起,并由系统调度其他进程运行。

其三,当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时,自然也会重新调度。

其四,当有优先级更高的进程运行时,为了保证高优先级进程的运行,当前进程会被挂起,由高优先级进程来运行。

最后一个,发生硬件中断时,CPU 上的进程会被中断挂起,转而执行内核中的中断服务程序。

线程与进程最大的区别在于, 线程是调度的基本单位,而进程则是资源拥有的基本单位

  • 当进程只有一个线程时,可以认为进程就等于线程。

  • 当进程拥有多个线程时,这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的。

  • 另外,线程也有自己的私有数据,比如栈和寄存器等,这些在上下文切换时也是需要保存的。

这么一来,线程的上下文切换其实就可以分为两种情况:

第一种, 前后两个线程属于不同进程。此时,因为资源不共享,所以切换过程就跟进程上下文切换是一样。

第二种,前后两个线程属于同一个进程。此时,因为虚拟内存是共享的,所以在切换时,虚拟内存这些资源就保持不动,只需要切换线程的私有数据、寄存器等不共享的数据。

到这里你应该也发现了,虽然同为上下文切换,但同进程内的线程切换,要比多进程间的切换消耗更少的资源,而这,也正是多线程代替多进程的一个优势。

为了快速响应硬件的事件, 中断处理会打断进程的正常调度和执行 ,转而调用中断处理程序,响应设备事件。而在打断其他进程时,就需要将进程当前的状态保存下来,这样在中断结束后,进程仍然可以从原来的状态恢复运行。

对同一个 CPU 来说,中断处理比进程拥有更高的优先级 ,所以中断上下文切换并不会与进程上下文切换同时发生。同样道理,由于中断会打断正常进程的调度和执行,所以大部分中断处理程序都短小精悍,以便尽可能快的执行结束。

  • 所谓 自愿上下文切换,是指进程无法获取所需资源,导致的上下文切换 。比如说, I/O、内存等系统资源不足时,就会发生自愿上下文切换。

  • 非自愿上下文切换,则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换 。比如说,大量进程都在争抢 CPU 时,就容易发生非自愿上下文切换。

  • 用户 CPU 和 Nice CPU 高,说明用户态进程占用了较多的 CPU,所以应该着重排查进程的性能问题。

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

  • I/O 等待 CPU 高,说明等待 I/O 的时间比较长,所以应该着重排查系统存储是不是出现了 I/O 问题。

  • 软中断和硬中断高,说明软中断或硬中断的处理程序占用了较多的 CPU,所以应该着重排查内核中的中断服务程序。

碰到常规问题无法解释的 CPU 使用率情况时,首先要想到有可能是短时应用导致的问题,比如有可能是下面这两种情况。

  • 第一, 应用里直接调用了其他二进制程序,这些程序通常运行时间比较短,通过 top 等工具也不容易发现

  • 第二, 应用本身在不停地崩溃重启,而启动过程的资源初始化,很可能会占用相当多的 CPU

  • 上半部直接处理硬件请求,也就是我们常说的硬中断,特点是快速执行;

  • 而下半部则是由内核触发,也就是我们常说的软中断,特点是延迟执行。

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型,可以通过查看 /proc/softirqs 来观察软中断的运行情况。

CPU 使用率描述了非空闲时间占总 CPU 时间的百分比,根据 CPU 上运行任务的不同,又被分为用户 CPU、系统 CPU、等待 I/O CPU、软中断和硬中断等。

  • 用户 CPU 使用率,包括用户态 CPU 使用率(user)和低优先级用户态 CPU 使用率(nice),表示 CPU 在用户态运行的时间百分比。用户 CPU 使用率高,通常说明有应用程序比较繁忙。

  • 系统 CPU 使用率,表示 CPU 在内核态运行的时间百分比(不包括中断)。系统 CPU 使用率高,说明内核比较繁忙。

  • 等待 I/O 的 CPU 使用率,通常也称为 iowait,表示等待 I/O 的时间百分比。iowait 高,通常说明系统与硬件设备的 I/O 交互时间比较长。

  • 软中断和硬中断的 CPU 使用率,分别表示内核调用软中断处理程序、硬中断处理程序的时间百分比。它们的使用率高,通常说明系统发生了大量的中断。

  • 除了上面这些,还有在虚拟化环境中会用到的窃取 CPU 使用率(steal)和客户 CPU 使用率(guest),分别表示被其他虚拟机占用的 CPU 时间百分比,和运行客户虚拟机的 CPU 时间百分比。

应用程序优化

  • 编译器优化 :很多编译器都会提供优化选项,适当开启它们,在编译阶段你就可以获得编译器的帮助,来提升性能。比如, gcc 就提供了优化选项 -O2,开启后会自动对应用程序的代码进行优化。

  • 算法优化 :使用复杂度更低的算法,可以显著加快处理速度。比如,在数据比较大的情况下,可以用 O(nlogn) 的排序算法(如快排、归并排序等),代替 O(n^2) 的排序算法(如冒泡、插入排序等)。

  • 异步处理 :使用异步处理,可以避免程序因为等待某个资源而一直阻塞,从而提升程序的并发处理能力。比如,把轮询替换为事件通知,就可以避免轮询耗费 CPU 的问题。

  • 多线程代替多进程 :前面讲过,相对于进程的上下文切换,线程的上下文切换并不切换进程地址空间,因此可以降低上下文切换的成本。

  • 善用缓存 :经常访问的数据或者计算过程中的步骤,可以放到内存中缓存起来,这样在下次用时就能直接从内存中获取,加快程序的处理速度。

系统优化

从系统的角度来说,优化 CPU 的运行,一方面要充分利用 CPU 缓存的本地性,加速缓存访问;另一方面,就是要控制进程的 CPU 使用情况,减少进程间的相互影响。

具体来说,系统层面的 CPU 优化方法也有不少,这里我同样列举了最常见的一些方法,方便你记忆和使用。

  • CPU 绑定 :把进程绑定到一个或者多个 CPU 上,可以提高 CPU 缓存的命中率,减少跨 CPU 调度带来的上下文切换问题。

  • CPU 独占 :跟 CPU 绑定类似,进一步将 CPU 分组,并通过 CPU 亲和性机制为其分配进程。这样,这些 CPU 就由指定的进程独占,换句话说,不允许其他进程再来使用这些 CPU。

  • 优先级调整 :使用 nice 调整进程的优先级,正值调低优先级,负值调高优先级。优先级的数值含义前面我们提到过,忘了的话及时复习一下。在这里,适当降低非核心应用的优先级,增高核心应用的优先级,可以确保核心应用得到优先处理。

  • 为进程设置资源限制 :使用 Linux cgroups 来设置进程的 CPU 使用上限,可以防止由于某个应用自身的问题,而耗尽系统资源。

  • NUMA(Non-Uniform Memory Access)优化 :支持 NUMA 的处理器会被划分为多个 node,每个 node 都有自己的本地内存空间。NUMA 优化,其实就是让 CPU 尽可能只访问本地内存。

  • 中断负载均衡 :无论是软中断还是硬中断,它们的中断处理程序都可能会耗费大量的 CPU。开启 irqbalance 服务或者配置 smp_affinity,就可以把中断处理过程自动负载均衡到多个 CPU 上。

linux性能优化实战-03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)

CPU上下文切换的分类

  1. 进程上下文切换
  2. 线程上下文切换
  3. 中断上下文切换

进程上下文切换

  1. 进程运行空间分为内核空间和用户空间,当进程在内核空间运行为内核态,在用户空间运行为用户态
  2. 用户态到内核态的转变需要系统调用来完成,系统调用过程一直是同一个进程在运行,
  3. 系统调用过程通常称为特权模式切换,而不是上下文切换,但实际,在系统调用过程中,CPU的上下文切换是无法避免的

进程上下文切换与系统调用的区别

首先进程是由内核来管理和调度的,进程的切换只能发生在内核态,所以,进程上下文不仅保罗了虚拟内存,栈,全局变量等用户空间的资源,还包括了内核堆栈,寄存器等内核空间的状态
因此进程上下文切换比系统调用多了一步

触发进程调度的时机

1.进程调度算法为每个进程分配了相同的运行时间片段,当时间耗尽的时候,相应进程被挂起,切换其他进程运行
2.进程在系统资源不足时,要等到资源满足后才可以运行,这个时候也会被挂起。
3.当进程通过睡眠函数sleep这样的方法主动将自己挂起时
4.当有更高级优先级的进程运行时
5.发生硬件终端时

线程上下文切换

分为同进程内的和不同进程间的上下文切换,其中不同进程间的线程上下文切换同进程上下文切换相同,同进程间的上下文切换,由于共用了进程的相关共用资源,因此此共用的部分不许需要保存切换,需要保存的仅仅是线程的独立栈和寄存器等。最终的内核中的任务调度,实际上的调度对象是线程,而进程仅仅提供了虚拟内存,全局变量等资源

线程与进程的区别:

1.进程是资源拥有的基本单位,线程是调度的基本单位。
2.当进程只有一个线程时,可以任务进程就等于线程
3.当进程拥有多个线程时,这些线程会共享相同的虚拟内存和全局变量等资源
4.线程也有自己的私有数据,比如栈和寄存器

中断上下文切换

中断处理通常会打断进程的正常调度和执行,转而调用中断处理程序
1.中断上下文切换不会涉及到进程的用户态。中断上下文,只包括了内核态中断服务程序执行所必须的状态,包括CPU寄存器,内核堆栈,硬件终端参数等
2.对同一个CPU来说,终端处理比进程有更高的优先级

理解平均负载

# 02 | 基础篇:到底应该怎么理解“平均负载”?
**简单概括:**平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和 CPU 使用率并没有直接关系。
**可运行状态的进程:**是指正在使用 CPU 或者正在等待 CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态(Running 或 Runnable)的进程。
**不可中断状态的进程:**则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的 I/O 响应,也就是我们在 ps 命令中看到的 D 状态(Uninterruptible Sleep,也称为 Disk Sleep)的进程。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

平均负载的合理值
平均负载最理想的情况是等于 CPU 个数。

平均负载异常情况
当平均负载高于 CPU 数量 70% 的时候,需要关注。

平均负载与 CPU 使用率
它不仅包括了正在使用 CPU 的进程,还包括等待 CPU 和等待 I/O 的进程。
而 CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应。比如:CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的;I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一定很高;大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。

02 | 基础篇:到底应该怎么理解“平均负载”?

03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)

04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)

面试题:

  • 自愿上下文切换和非自愿上下文切换区别是什么?(或是自愿上下文切换和非自愿上下文切换会在什么场景下发生)
    答:自愿上下文切换,是指进程无法获取所需资源,导致的上下文切换。比如说, I/O、内存等系统资源不足时,就会发生自愿上下文切换。非自愿上下文切换,则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换。比如说,大量进程都在争抢 CPU 时,就容易发生非自愿上下文切换。

平均负载

KallyDev 于 2020 年 6 月 1 日的学习笔记

基本概念

• 平均负载 (Load average)
单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和 CPU 的使用率并没有直接关系。

• 可运行状态
正在使用 CPU 或者正在等待 CPU 的进程。例如使用 ps 命令所看到的处于 R 状态(Running 或 Runnable)的进程。

• 不可中断状态
正处于内核态关键流程中的进程,并这些流程是不可打断的。也就是使用 ps 命令所看到的处于 D 状态(Uninterruptible/Disk Sleep)的进程。例如一个进程向磁盘读写数据时,为了保证数据一致性,在磁盘响应前不能被其他进程影响。

基本操作

• 查看平均负载

$ uptime
03:48:43 up 2 days,  3:43,  0 users,  load average: 0.40, 0.51, 0.56

输出的各个值分别为当前时间、运行时间、当前已登录的用户数,1、5、15 分钟内的平均负载。

• 查看 CPU 核心数

$ grep 'model name' /proc/cpuinfo | wc -l
1

查询 CPU 的详细信息也可以使用 lscpu 命令。

场景模拟

准备了一台 1C2G 的服务器,操作系统为 Ubuntu Server 18.04 LTS。首先需要安装 stress 和 sysstat 工具。

$ sudo apt install -y stress sysstat

stress 和 sysstat 常用于性能测试与分析。其中,stress 是一款 Linux 系统压力测试工具,可以用于模拟异常进程并提高平均负载。而 sysstat 则包含了常用的 Linux 性能分析工具,例如 mpstat 和 pidstat 命令。

• mpstat
查看每个或全部 CPU 的性能指标。

$ mpstat
Linux 4.15.0-91-generic (ubuntu)        05/31/2020      _x86_64_   (1 CPU)

11:51:12 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
11:51:12 PM  all    0.05    0.00    0.04    0.00    0.00    0.00    0.00    0.00    0.00   99.90

• pidstat
实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

$ pidstat
Linux 4.15.0-91-generic (ubuntu)        05/31/2020      _x86_64_   (1 CPU)

11:52:33 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11:52:33 PM     0         1    0.00    0.00    0.00    0.00    0.00     0  systemd
11:52:33 PM     0         2    0.00    0.00    0.00    0.00    0.00     0  kthreadd
11:52:33 PM     0         7    0.00    0.00    0.00    0.00    0.00     0  ksoftirqd/0
...

首先打开终端 A,使用 watch 运行 uptime 实时查看平均负载。

$ watch -d uptime
Every 2.0s: uptime    ubuntu: Sun May 31 22:16:32 2020
22:16:32 up 9 days,  3:27,  1 user,  load average: 0.25, 0.18, 0.16

然后打开终端 B,使用 mpstat 每隔 5 秒查看 CPU 使用率变化。

$ mpstat -P ALL 5
Linux 4.15.0-91-generic (ubuntu)        06/01/2020      _x86_64_   (1 CPU)

10:26:30 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:26:35 AM  all    0.20    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.60
10:26:35 AM    0    0.20    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.60

场景模拟

CPU 密集型

在终端 C 使用 stress 模拟一个 CPU 使用 100% 的场景,并观察终端 A 中平均负载的变化。

$ stress --cpu 1 --timeout 600
stress: info: [4098] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

从终端 A 可以发现,1 分钟内的平均不断上升到 1.00 左右,而 5 分钟内平均负载上升到 0.50 左右。

而在终端 B 中可以看到有一个 CPU 使用率为 100%,同时 iowait 为 0.00,由此可以定位到性能问题是由 CPU 的满载使用率导致的。

但现在依然不知道是什么原因导致的 CPU 满载,需要使用 pidstat 尝试定位到 CPU 消耗大的进程。

$ pidstat -u 5 1
Linux 4.15.0-91-generic (ubuntu)        06/01/2020      _x86_64_   (1 CPU)

10:34:47 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
10:34:52 AM     0       449    0.20    0.20    0.00    0.00    0.40     0  dockerd
10:34:52 AM     0      4099   99.20    0.00    0.00    0.80   99.20     0  stress
10:34:52 AM     0      4209    0.00    0.20    0.00    0.20    0.20     0  pidstat

查看输出信息,可以看到 PID 4099 名为 stress 的进程消耗了 99.20% 的 CPU,它就是罪魁祸首了。

I/O 密集型

使用 stresa 模拟一个 IO 密集型进程。

$ stress -i 1 --timeout 600
stress: info: [5011] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

在终端 A 可以看到,1 分钟内的平均负载达到了 1.00 左右。在终端 B 中,CPU 为 22.36%,而 iowait 达到了 71.04%,由此可见此次性能问题是由 I/O 引起。

$ pidstat -u 5 1
Linux 4.15.0-91-generic (ubuntu)        06/01/2020      _x86_64_   (1 CPU)

10:50:26 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
10:50:31 AM     0       181    0.00   10.96    0.00    0.00   10.96     0  kworker/0:1H
10:50:31 AM     0       449    0.20    0.00    0.00    0.00    0.20     0  dockerd
10:50:31 AM     0      4856    0.00    0.20    0.00    0.00    0.20     0  kworker/u2:1
10:50:31 AM     0      5012    0.00   16.14    0.00   11.16   16.14     0  stress

可以发现,其中 PID 5012 的 stress 进程最终导致了性能问题。

大量进程的场景

使用 stress 模拟 4 个 CPU 密集型进程。

$ stress -c 4 --timeout 600
stress: info: [6777] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

由于服务器的 CPU 只有 1 个,而 4 个进程远比 1 大 4 倍。因此,终端 A 中显示的平均负载达到了 4.00 左右。

通过 pidstat 也可以发现,有四个进程的 wait 高达 75%,也就是每个进程只能及时的分配到 25%。四个进程能分配的总和刚好为服务器最大所能提供 100% 的 CPU。

$ pidstat -u 5 1
Linux 4.15.0-91-generic (ubuntu)        06/01/2020      _x86_64_   (1 CPU)

10:57:16 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
10:57:21 AM     0       449    0.20    0.00    0.00    0.00    0.20     0  dockerd
10:57:21 AM     0      6778   24.50    0.00    0.00   75.10   24.50     0  stress
10:57:21 AM     0      6779   24.70    0.00    0.00   75.10   24.70     0  stress
10:57:21 AM     0      6780   24.70    0.20    0.00   75.10   24.90     0  stress
10:57:21 AM     0      6781   24.70    0.00    0.00   75.30   24.70     0  stress
10:57:21 AM     0      6901    0.00    0.20    0.00    0.20    0.20     0  pidstat

小结

• 平均负载高有可能由 CPU 密集型进程导致;
• 平均负载高并不一定代表 CPU 使用率高,还有可能是 I/O 繁忙;
• 当发现负载高的时候,可以使用 mpstat、pidstat 等工具,辅助分析负载的来源;

第一周学习笔记

前言

虽然一直从事运维工作,对于Linux操作系统也算是轻车熟路,Linux系统高效的原因之一就是一切皆命令,固然,熟练掌握常用的一些命令那是重中之重。

到底什么是系统平均负载?

对于这个问题,以前也是停留在表层,也只是冰山一角,对它的理解,就是系统的平均负载——即整个系统在单位时间内,1分钟,5分钟,15分钟内整个Linux系统的平均负载,包括cpu,内存,磁盘io等等性能。

当然,后来也经过GooGle查找相关资料,但是也只是过一眼,没深入去理解,也没系统的全面的去了解,经过这次学习,有了更深的理解,当然学无止境,随着工作中和后面经验的增加,可能理解会越来越深刻。

什么是平均负载:

  • 列表条目

简单来说,就是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数。(它跟 CPU 使用率没有直接关系。)

  • 列表条目

可运行状态,是指正在使用 CPU 或者正在等待 CPU 的进程,也就是通过 ps 命令看到的处于 R 状态的进程。

  • 列表条目

不可中断状态的进程是指正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如等待硬件设备 IO 响应,ps 命令看到的 D 状态(Uninterruptible Sleep,也称为 Disk Sleep )的进程。

不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

个人理解

以我个人的理解,平均负载主要是指系统平均的进程数量,而进程的状态为处于可运行状态,和不可中断状态,那么跟我之前单纯的理解为cpu使用率和内存使用率相差是很大的,当然,虽然没有直接的关系,整个系统是相互联系的,或多多少也会有间接的联系。

当然说到进程,就牵扯到很多系统层面的了,用户态,内核态,上下文切换等等,这个先不做讨论。重要的是这次学习,更了解到各个命令间的相互配合,找出系统的“真正元凶”,比如常用的 top,iostat, pidstat, mpstat等等,因为之前都是直接看监控作分析,当然,系统性能指标的监控离不开这些系统性能命令。

最后,革命尚未成功,还需继续学习。还是那句话,牵一发而动全身,需要各个击破。加油!

平均負載Load Average

進度有點緩慢,很多都是過往沒注意過的內容,先擠出這一些

CPU篇

理解平均负载

平均负载指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数。

  • 可运行状态进程
    可运行状态进程指正在使用或者正在等待CPU的进程。
  • 不可中断状态进程
    不可中断状态的进程指正处于内核态关键流程中的进程。比如等待IO。

平均负载的影响因素:

  1. CPU密集型
  2. IO密集型
  3. 大量进程导致频繁的调度,-> CPU上下文切换频繁。

CPU上下文切换

CPU上下文 是指CPU寄存器和程序计数器所依赖的环境。
CPU上下文切换: 保存旧的,加载新的,跳转运行。

三种切换类型:

  1. 进程上下文切换
  2. 线程上下文切换
  3. 中断

自愿型和非自愿型切换:

  1. 自愿上下文切换,是指进程无法获取所需资源,导致的上下文切换。
  2. 非自愿上下文切换,则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换。

2020/06/01 小结

上周由于同时在进行一些别的事情,因此这方面的进度会比较慢,下周赶进度。主要收获如下

  • 基本概念理解

    • CPU 信息统计

    • 平均负载 vs CPU 利用率

    • 上下文切换

  • 工具命令学习

    • CPU 信息统计:/proc/cpuinfo && lscpu

    • 压测命令:stress

    • Sysstat 工具包

      • mpstat:逻辑 CPU 统计数据

      • pidstat:进程统计数据

        • -u:cpu

        • -r:内存

        • -w:上下文切换

        • -t:线程额外统计

        • -d:I/O

    • vmstat:服务器整体统计数据

    • sysbench:多线程模拟工具使用

    • 持续观察状态变化的命令:watch -d {exec_cmd}

    • 基础概念的理解 + 高效的诊断工具 --> 快速定位系统问题

  • 后续学习计划

    • 看群里有些大牛怎么怎么去分析 linux kernel 的行为,暂且不说理论的正确性,目前这块不适合我。作为一个业务开发的 RD 关注重点在于基础概念整体框架的搭建,注重于线上生产环境中解决实际问题。

1、基础篇:到底应该怎么理解“平均负载”

http://note.youdao.com/noteshare?id=b623eeda834a6166dd00ece5a26967a7

请问一下你的排查图是用啥画出来,怎么画出来的。 :grinning:

插图是专栏作者画的吧?

刚看到专栏11讲,是里面的图。以为是整理处理,这一章刚好解决心中的疑问。

理解CPU使用率和CPU上下文切换

理解中断.

理解内存