linux性能优化学习笔记(持续学习更新Ing)
2021-03-11 13:18:24 1 举报AI智能生成
极客时间linux性能优化实战笔记
作者其他创作
大纲/内容
average:0.63 0.83 0.88
top命令或uptime命令
可运行状态进程：正在使用CPU或者正在等待CPU进程的进程，也就是我们常用ps命令看到的，处于R状态的进程
不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些进程是不可打断的，比如最常见的是等待硬件设备的I/O响应，ps命令中看拿到的D状态进程
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系
既然是平活跃进程数，则当每个CPU上都刚好运行着一个进程是最理想的。
3个数值，分别代表过去 1分钟 5分钟 、15分钟的负载时间段
CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
平均负载高不等于CPU使用率高
mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
# 间隔5秒后输出一组数据$ pidstat -u 5 113:37:07 UID PID %usr %system %guest %wait %CPU CPU Command13:37:12 0 2962 100.00 0.00 0.00 0.00 100.00 1 stress
pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标
学习命令
第2讲，怎么理解平均负载
CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。而程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境
cpu上下文
就是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。
什么是CPU 上下文切换
内核空间（Ring 0）具有最高权限，可以直接访问所有资
用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源
图
等级介绍
进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态
系统调用例子：当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件
两次切换：CPU 寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU 寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务
从用户态到内核态的转变，需要通过系统调用来完成，一次系统调用的过程，其实是发生了两次 CPU 上下文切换
系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上，系统调用过程中，CPU 的上下文切换还是无法避免的。
linux特权等级
进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以，进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。因此，进程的上下文切换就比系统调用时多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈
根据 Tsuna 的测试报告，每次上下文切换都需要几十纳秒到数微秒的 CPU 时间。这个时间还是相当可观的，特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。这也正是上一节中我们所讲的，导致平均负载升高的一个重要因素。
CPU里有一个TLB translation lookaside buffer，用于缓存虚拟内存到物理内存映射关系的页表，如果发生上下文切换，会导致该部分缓冲的上一个进程的页表映射关系成为脏页，此时CPU会刷新整个TLB为新进程的页表。在多核处理器中，TLB是它们共享的，频繁刷脏导致命中率下降，CPU会通过页表转换之后访问物理地址，此时性能是明显低于直接访问TLB里缓存的物理地址的。 https://blog.csdn.net/hnwyllmm/article/details/77051135?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
Linux 通过 TLB（Translation Lookaside Buffer）来管理虚拟内存到物理内存的映射关系。当虚拟内存更新后，TLB 也需要刷新，内存的访问也会随之变慢。特别是在多处理器系统上，缓存是被多个处理器共享的，刷新缓存不仅会影响当前处理器的进程，还会影响共享缓存的其他处理器的进程。
性能问题：
其一，为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。
其二，进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。
其三，当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度
其四，当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行
最后一个，发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。
进程切换场景
进程上下文切换
当进程只有一个线程时，可以认为进程就等于线程。
当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的
线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的。
进程与线程关系情况
第一种， 前后两个线程属于不同进程。此时，因为资源不共享，所以切换过程就跟进程上下文切换是一样
第二种，前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据
线程上下文切换场景
线程上下文切换
为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行
跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。中断上下文，其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等。
对同一个 CPU 来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生。同样道理，由于中断会打断正常进程的调度和执行，所以大部分中断处理程序都短小精悍，以便尽可能快的执行结束。
另外，跟进程上下文切换一样，中断上下文切换也需要消耗 CPU，切换次数过多也会耗费大量的 CPU，甚至严重降低系统的整体性能。所以，当你发现中断次数过多时，就需要注意去排查它是否会给你的系统带来严重的性能问题
中断上下文切换
不同的切换场景
第三讲CPU上下文切换
# 每隔5秒输出1组数据$ vmstat 5procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 7005360 91564 818900 0 0 0 0 25 33 0 0 100 0 0
cs（context switch）是每秒上下文切换的次数。
in（interrupt）则是每秒中断的次数。
r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。
b（Blocked）则是处于不可中断睡眠状态的进程数。
us（user）用户态调用CPU使用率
sy（system）内核态调用CPU使用率
是一个常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析 CPU 上下文切换和中断的次数
vmstat（系统总体）
# 每隔5秒输出1组进程数据$ pidstat -w 5Linux 4.15.0 (ubuntu) 09/23/18 _x86_64_ (2 CPU)08:18:26 UID PID cswch/s nvcswch/s Command08:18:31 0 1 0.20 0.00 systemd08:18:31 0 8 5.40 0.00 rcu_sched...
所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换
cswch ，表示每秒自愿上下文切换（voluntary context switches）的次数
而非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换
nvcswch ，表示每秒非自愿上下文切换（non voluntary context switches）的次数。
pidstat查看每个进程（线程）上下文切换情况
命令介绍
# 每隔1秒输出1组数据（需要Ctrl+C才结束）$ vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 6 0 0 6487428 118240 1292772 0 0 0 0 9019 1398830 16 84 0 0 0 8 0 0 6487428 118240 1292772 0 0 0 0 10191 1392312 16 84 0 0 0
r 列：就绪队列的长度已经到了 8，远远超过了系统 CPU 的个数 2，所以肯定会有大量的 CPU 竞争。
us（user）和 sy（system）列：这两列的 CPU 使用率加起来上升到了 100%，其中系统 CPU 使用率，也就是 sy 列高达 84%，说明 CPU 主要是被内核占用了
in 列：中断次数也上升到了 1 万左右，说明中断处理也是个潜在的问题
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高
运行vmstat时发现
卡住点
# 每隔1秒输出1组数据（需要 Ctrl+C 才结束）# -w参数表示输出进程切换指标，而-u参数则表示输出CPU使用指标$ pidstat -w -u 108:06:33 UID PID %usr %system %guest %wait %CPU CPU Command08:06:34 0 10488 30.00 100.00 0.00 0.00 100.00 0 sysbench08:06:34 0 26326 0.00 1.00 0.00 0.00 1.00 0 kworker/u4:208:06:33 UID PID cswch/s nvcswch/s Command08:06:34 0 8 11.00 0.00 rcu_sched08:06:34 0 16 1.00 0.00 ksoftirqd/108:06:34 0 471 1.00 0.00 hv_balloon08:06:34 0 1230 1.00 0.00 iscsid08:06:34 0 4089 1.00 0.00 kworker/1:508:06:34 0 4333 1.00 0.00 kworker/0:308:06:34 0 10499 1.00 224.00 pidstat08:06:34 0 26326 236.00 0.00 kworker/u4:208:06:34 1000 26784 223.00 0.00 sshd
CPU 使用率的升高果然是 sysbench 导致的，它的 CPU 使用率已经达到了 100%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd。
pidstat 输出的上下文切换次数，加起来也就几百，比 vmstat 的 139 万明显小了太多。这是怎么回事呢？
1.运行pidstat查看进程上下文切换情况
# 每隔1秒输出一组数据（需要 Ctrl+C 才结束）# -wt 参数表示输出线程的上下文切换指标$ pidstat -wt 108:14:05 UID TGID TID cswch/s nvcswch/s Command...08:14:05 0 10551 - 6.00 0.00 sysbench08:14:05 0 - 10551 6.00 0.00 |__sysbench08:14:05 0 - 10552 18911.00 103740.00 |__sysbench08:14:05 0 - 10553 18915.00 100955.00 |__sysbench08:14:05 0 - 10554 18827.00 103954.00 |__sysbench...
虽然 sysbench 进程（也就是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来，上下文切换罪魁祸首，还是过多的 sysbench 线程。
既然是中断，我们都知道，它只发生在内核态，而 pidstat 只是一个进程的性能分析工具，并不提供任何关于中断的详细信息
中断次数上升到1w的原因还没找到？
2.运行pidstat查看线程上下文切换情况
# -d 参数表示高亮显示变化的区域$ watch -d cat /proc/interrupts CPU0 CPU1...RES: 2450431 5279697 Rescheduling interrupts...
变化速度最快的是重调度中断（RES），这个中断类型表示，唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统（SMP）中，调度器用来分散任务到不同 CPU 的机制，通常也被称为处理器间中断
所以，这里的中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的
3.从 /proc/interrupts 这个只读文件中读取中断情况
排查解决
这个数值其实取决于系统本身的 CPU 性能。在我看来，如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题
每秒上下文切换多少次才算正常呢？
自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题
非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈；
中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型
根据上下文切换的类型，做具体分析
总结收获
第四讲：分析上下文切换(案例分析)
user（通常缩写为 us），代表用户态 CPU 时间。注意，它不包括下面的 nice 时间，但包括了 guest 时间
nice（通常缩写为 ni），代表低优先级用户态 CPU 时间，也就是进程的 nice 值被调整为 1-19 之间时的 CPU 时间。这里注意，nice 可取值范围是 -20 到 19，数值越大，优先级反而越低。
system（通常缩写为 sys），代表内核态 CPU 时间。
idle（通常缩写为 id），代表空闲时间。注意，它不包括等待 I/O 的时间（iowait）
iowait（通常缩写为 wa），代表等待 I/O 的 CPU 时间
irq（通常缩写为 hi），代表处理硬中断的 CPU 时间。
softirq（通常缩写为 si），代表处理软中断的 CPU 时间
steal（通常缩写为 st），代表当系统运行在虚拟机中的时候，被其他虚拟机占用的 CPU 时间
guest（通常缩写为 guest），代表通过虚拟化运行其他操作系统的时间，也就是运行虚拟机的 CPU 时间
guest_nice（通常缩写为 gnice），代表以低优先级运行虚拟机的时间
使用率相关指标
性能工具一般都会取间隔一段时间（比如 3 秒）的两次值，作差后，再计算出这段时间内的平均 CPU 使用率（多个工具对比cpu时，注意间隔时间的设置）
top 默认使用 3 秒时间间隔，而 ps 使用的却是进程的整个生命周期。
就是除了空闲时间外的其他时间占总 CPU 时间的百分比
%Cpu(s):第三行 %Cpu 就是系统所有的CPU 使用率(注意单位是百分比，不是时间)，可按1来查看各个cpu的使用率
空白行之后是进程的实时信息，每个进程都有一个 %CPU 列，表示进程的 CPU 使用率。它是用户态和内核态 CPU 使用率的总和，包括进程用户空间使用的 CPU、通过系统调用执行的内核空间 CPU 、以及在就绪队列等待运行的 CPU。在虚拟化环境中，它还包括了运行虚拟机占用的 CPU
top 并没有细分进程的用户态 CPU 和内核态 CPU，若需要细分，则需使用pidstat命令
top
# 每隔1秒输出一组数据，共输出5组$ pidstat 1 515:56:02 UID PID %usr %system %guest %wait %CPU CPU Command15:56:03 0 15006 0.00 0.99 0.00 0.00 0.99 1 dockerdAverage: UID PID %usr %system %guest %wait %CPU CPU CommandAverage: 0 15006 0.00 0.99 0.00 0.00 0.99 - dockerd
pidstat
使用率查看命令
1.使用top ps pidstat等命令就能确定是哪个进程的问题了
2.如何实时查看进程占用CPU时钟最多的函数或者指令？采用perf命令
第一列 Overhead ，是该符号的性能事件在所有采样中的比例，用百分比来表示
第二列 Shared ，是该函数或指令所在的动态共享对象（Dynamic Shared Object），如内核、进程名、动态链接库名、内核模块名等
第三列 Object ，是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库，而 [k] 则表示内核空间
最后一列 Symbol 是符号名，也就是函数名。当函数名未知时，用十六进制的地址来表示
第一行包含三个数据，分别是采样数（Samples）、事件类型（event）和事件总数量（Event count）。比如这个例子中，perf 总共采集了 833 个 CPU 时钟事件，而总事件数则为 97742399。采样数需要我们特别注意。如果采样数过少（比如只有十几个），那下面的排序和百分比就没什么实际参考价值了
该命令缺点是并不保存数据，无法用于离线或者后续的分析
1. perf top实时查看进程占用CPU时钟最多的函数或者指令
2.perf record 和 perf report 命令可以保存数据并分析
2.如何更精准地排查？使用perf工具
CPU使用率过高如何排查？
用户 CPU 和 Nice CPU 高，说明用户态进程占用了较多的 CPU，所以应该着重排查进程的性能问题
系统 CPU 高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题
I/O 等待 CPU 高，说明等待 I/O 的时间比较长，所以应该着重排查系统存储是不是出现了 I/O 问题
软中断和硬中断高，说明软中断或硬中断的处理程序占用了较多的 CPU，所以应该着重排查内核中的中断服务程序
常见CPU使用率高问题
CPU 使用率
第五讲，cpu使用率介绍
top命令发现用户cpu使用率(us)高达80%，但是没有一个进程是cpu高的
pidstat命令 也没发现cpu高的进程
1.观察到top命令 Tasks一行，就绪队列有6个running状态进程，但是nginx、php-fpm都处于sleep状态。处于running的是几个stress进程
说明stress进程已经关闭了
pidstat stress进程以及ps |grep 都没有内容输出
既然进程没了，性能问题应该也没了，再用top确认一下
1.进程在不停地奔溃重启，比如因为段错误、配置错误等等，这时，进程在退出后可能又被监控你那个系统自动重启了
2.这些进程都是短时进程，也就是在其他应用内部通过excec调用的外面命令
发现cpu问题还在，但是stress进程的pid变化了。可能原因：
通过pstree查询进程的父进程，发现stress是被php-fpm调用的子进程，并且进程数量不止一个
直接grep stress 源码，找到对应代码，发现stress模拟的是I/O压力，而top看到的却是cpu升高，并没见到iowait升高，怎么回事？
运行perf record -g命令 ，并且等一会后(例如15秒)退出，并用perf report查看报告
从报告可看出stress占了77%的cpu时钟事件，而stress调用栈中比例最高的，是函数random()
使用perf命令分析cpu性能能事件
解决思路
1.应用里直接调用了其他二进制程序，这些程序通常运行时间内比较短，通过top等工具也不容易发现
2.应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的CPU
总结：碰到常规问题无法解释的cpu使用率情况时，首先要想到有可能是短时应用导致的问题，比如：
第6篇，用户cpu使用率高，但找不到高cpu的应用
当 iowait 升高时，进程很可能因为得不到硬件的响应，而长时间处于不可中断状态。
R 是 Running 或 Runnable 的缩写，表示进程在 CPU 的就绪队列中，正在运行或者正在等待运行。
进程长时间处于不可中断状态，通常表示系统有 I/O 性能问题
D 是 Disk Sleep 的缩写，也就是不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断。
短暂的僵尸状态我们通常不必理会，但进程长时间处于僵尸状态，就应该注意了，可能有应用程序没有正常处理子进程的退出。
Z 是 Zombie 的缩写，它表示僵尸进程，也就是进程实际上已经结束了，但是父进程还没有回收它的资源（比如进程的描述符、PID 等）。
S 是 Interruptible Sleep 的缩写，也就是可中断状态睡眠，表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时，它会被唤醒并进入 R 状态。
I 是 Idle 的缩写，也就是空闲状态，用在不可中断睡眠的内核线程上。前面说了，硬件交互导致的不可中断进程用 D 表示，但对某些内核线程来说，它们有可能实际上并没有任何负载，用 Idle 正是为了区分这种情况。要注意，D 状态的进程会导致平均负载升高， I 状态的进程却不会。
T 或者 t，也就是 Stopped 或 Traced 的缩写，表示进程处于暂停或者跟踪状态。向一个进程发送 SIGSTOP 信号，它就会因响应这个信号变成暂停状态（Stopped）；再向它发送 SIGCONT 信号，进程又会恢复运行（如果进程是终端里直接启动的，则需要你用 fg 命令，恢复到前台运行）
X，也就是 Dead 的缩写，表示进程已经消亡，所以你不会在 top 或者 ps 命令中看到它。
进程组表示一组相互关联的进程，比如每个子进程都是父进程所在组的成员
而会话是指共享同一个控制终端的一个或多个进程组。
使用ps和top命令时，进程状态(S)一列的各个值含义
dstat工具命令以同时查看 CPU 和 I/O 这两种资源的使用情况，便于对比分析
先看第一行的平均负载（ Load Average），过去 1 分钟、5 分钟和 15 分钟内的平均负载在依次减小，说明平均负载正在升高；而 1 分钟内的平均负载已经达到系统的 CPU 个数，说明系统很可能已经有了性能瓶颈
再看第二行的 Tasks，有 1 个正在运行的进程，但僵尸进程比较多，而且还在不停增加，说明有子进程在退出时没被清理
接下来看两个 CPU 的使用率情况，用户 CPU 和系统 CPU 都不高，但 iowait 分别是 60.5% 和 94.6%，好像有点儿不正常
最后再看每个进程的情况， CPU 使用率最高的进程只有 0.3%，看起来并不高；但有两个进程处于 D 状态，它们可能在等待 I/O，但光凭这里并不能确定是它们导致了 iowait 升高
iowait 太高了，导致系统的平均负载升高，甚至达到了系统 CPU 的个数
僵尸进程在不断增多，说明有程序没能正确清理子进程的资源
总结问题：
问题：top发现异常
从 dstat 的输出，我们可以看到，每当 iowait 升高（wai）时，磁盘的读请求（read）都会很大。这说明 iowait 的升高跟磁盘的读请求有关，很可能就是磁盘读导致的
使用dstat查看CPU 、I/O的资源使用情况，并对比分析
# 间隔 1 秒输出多组数据 (这里是 20 组)$ pidstat -d 1 20...06:48:46 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:47 0 4615 0.00 0.00 0.00 1 kworker/u4:106:48:47 0 6080 32768.00 0.00 0.00 170 app06:48:47 0 6081 32768.00 0.00 0.00 184 app06:48:47 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:48 0 6080 0.00 0.00 0.00 110 app06:48:48 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:49 0 6081 0.00 0.00 0.00 191 app06:48:49 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:50 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:51 0 6082 32768.00 0.00 0.00 0 app06:48:51 0 6083 32768.00 0.00 0.00 0 app06:48:51 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:52 0 6082 32768.00 0.00 0.00 184 app06:48:52 0 6083 32768.00 0.00 0.00 175 app06:48:52 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command06:48:53 0 6083 0.00 0.00 0.00 105 app...
kB_rd 表示每秒读的 KB 数， kB_wr 表示每秒写的 KB 数，iodelay 表示 I/O 的延迟（单位是时钟周期）
app 进程在进行磁盘读，并且每秒读的数据有 32 MB，看来就是 app 的问题
使用pidstat查看各进程的io使用情况
$ ps aux | grep 6082root 6082 0.0 0.0 0 0 pts/0 Z+ 13:43 0:00 [app] <defunct>
查询失败，再检查下进程状态是否正常
发现该app进程已经变成僵尸进程，但系统 iowait 的问题还在继续
尝试使用strace命令跟踪下进程的系统调用（访问磁盘必须使用系统调用）
找到我们关注的 app 进程，按回车键展开调用栈，你就会得到下面这张调用关系图
$ perf record -g$ perf report
app 的确在通过系统调用 sys_read() 读取数据。并且从 new_sync_read 和 blkdev_direct_IO 能看出，进程正在对磁盘进行直接读，也就是绕过了系统缓存，每个读请求都会从磁盘直接读，这就可以解释我们观察到的 iowait 升高了
至此能确定是app进程导致的iowait问题
使用perf top查看app进程的调用栈
通过pstree找到这些僵尸进程的父进程还是app进程
查看业务代码问题： 没有调用 wait() 或 waitpid() ，抑或是，有没有注册 SIGCHLD 信号的处理函数。
iowait问题解决后，僵尸进程还是不停增加？
排查
案例分析
iowait 高不一定代表 I/O 有性能瓶颈。当系统中只有 I/O 类型的进程在运行时，iowait 也会很高，但实际上，磁盘的读写远没有达到性能瓶颈的程度。
第7+8讲，处理大量不可中断进程和僵尸进程（iowait升高）
上半部直接处理硬件请求，也就是我们常说的硬中断，特点是快速执行
上半部对应硬件中断，用来快速处理中断，它在中断禁止模式下运行，主要处理跟硬件紧密相关的或时间敏感的工作。
而下半部则是由内核触发，也就是我们常说的软中断，特点是延迟执行
Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，可以通过查看 /proc/softirqs 来观察软中断的运行情况
下半部对应软中断，用来异步处理上半部未完成的工作，通常以内核线程的方式运行。
linux中的中断处理程序分为上半部和下半部
网卡接收到数据包后，硬件中断：的方式把网卡的数据读到内存中，然后更新一下硬件寄存器的状态（表示数据已经读好了），最后再发送一个软中断信号，通知下半部做进一步的处理软中断：下半部被软中断信号唤醒后，需要从内存中找到网络数据，再按照网络协议栈，对数据进行逐层解析和处理，直到把它送给应用程序
中断举例
第一，要注意软中断的类型，也就是这个界面中第一列的内容。从第一列你可以看到，软中断包括了 10 个类别，分别对应不同的工作类型。比如 NET_RX 表示网络接收中断，而 NET_TX 表示网络发送中断。第二，要注意同一种软中断在不同 CPU 上的分布情况，也就是同一行的内容。正常情况下，同一种中断在不同 CPU 上的累积次数应该差不多。比如这个界面中，NET_RX 在 CPU0 和 CPU1 上的中断次数基本是同一个数量级，相差不大
/proc/softirqs 提供了软中断的运行情况
/proc/interrupts 提供了硬中断的运行情况。
查看中断情况
每个 CPU 都对应一个软中断内核线程，这个软中断内核线程就叫做 ksoftirqd/CPU 编号
$ ps aux | grep softirqroot 7 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/0]root 16 0.0 0.0 0 0 ? S Oct10 0:01 [ksoftirqd/1]
查看软中断内核线程
第9讲，中断概念讲解
sar 是一个系统活动报告工具，既可以实时查看系统的当前活动，又可以配置保存和报告历史统计数据
sar
hping3 是一个可以构造 TCP/IP 协议数据包的工具，可以对系统进行安全审计、防火墙测试等
hping3
tcpdump 是一个常用的网络抓包工具，常用来分析各种网络问题
tcpdump
watch可以帮你监测一个命令的运行结果，省得你一遍遍的手动运行。在Linux下，watch 是周期性的执行下个程序，并全屏显示执行结果。你可以拿他来监测你想要的一切命令的结果变化，比如 tail 一个 log 文件，ls 监测某个文件的大小变化，看你的想象力
watch
工具
1.系统响应变慢，终端敲回车响应都很久
平均负载全是 0，就绪队列里面只有一个进程（1 running）。
每个 CPU 的使用率都挺低，最高的 CPU1 的使用率也只有 4.4%，并不算高。
再看进程列表，CPU 使用率最高的进程也只有 0.3%，还是不高呀。
两个 CPU 的使用率虽然分别只有 3.3% 和 4.4%，但都用在了软中断上；而从进程列表上也可以看到，CPU 使用率最高的也是软中断进程 ksoftirqd。看起来，软中断有点可疑了
2.使用top命令查看系统整体资源使用情况
问题点
$ watch -d cat /proc/softirqs CPU0 CPU1 HI: 0 0 TIMER: 1083906 2368646 NET_TX: 53 9 NET_RX: 1550643 1916776 BLOCK: 0 0 IRQ_POLL: 0 0 TASKLET: 333637 3930 SCHED: 963675 2293171 HRTIMER: 0 0 RCU: 1542111 1590625
通过 /proc/softirqs 文件内容的变化情况，你可以发现， TIMER（定时中断）、NET_RX（网络接收）、SCHED（内核调度）、RCU（RCU 锁）等这几个软中断都在不停变化。其中，NET_RX，也就是网络数据包接收软中断的变化速率最快。而其他几种类型的软中断，是保证 Linux 调度、时钟和临界区保护这些正常工作所必需的，所以它们有一定的变化倒是正常的。
1.查看/proc/softirqs，观察中断数据
第一列：表示报告的时间
第二列：IFACE 表示网卡
第三、四列：rxpck/s 和 txpck/s 分别表示每秒接收、发送的网络帧数，也就是 PPS
第五、六列：rxkB/s 和 txkB/s 分别表示每秒接收、发送的千字节数，也就是 BPS。
# -n DEV 表示显示网络收发的报告，间隔1秒输出一组数据$ sar -n DEV 115:03:46 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil15:03:47 eth0 12607.00 6304.00 664.86 358.11 0.00 0.00 0.00 0.0115:03:47 docker0 6302.00 12604.00 270.79 664.66 0.00 0.00 0.00 0.0015:03:47 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.0015:03:47 veth9f6bbcd 6302.00 12604.00 356.95 664.66 0.00 0.00 0.00 0.05
docker0 和 veth9f6bbcd 的数据跟 eth0 基本一致，只是发送和接收相反，发送的数据较大而接收的数据较小。这是 Linux 内部网桥转发导致的，你暂且不用深究，只要知道这是系统把 eth0 收到的包转发给 Nginx 服务即可
对网卡 eth0 来说，每秒接收的网络帧数比较大，达到了 12607，而发送的网络帧数则比较小，只有 6304；每秒接收的千字节数只有 664 KB，而发送的千字节数更小，只有 358 KB
接收的 PPS 比较大，达到 12607，而接收的 BPS 却很小，只有 664 KB。直观来看网络帧应该都是比较小的，我们稍微计算一下，664*1024/12607 = 54 字节，说明平均每个网络帧只有 54 字节，这显然是很小的网络帧，也就是我们通常所说的小包问题。
2.使用sar查看系统的网络收发情况
192.168.0.2.18238 > 192.168.0.30.80 ，表示网络帧从 192.168.0.2 的 18238 端口发送到 192.168.0.30 的 80 端口，也就是从运行 hping3 机器的 18238 端口发送网络帧，目的为 Nginx 所在机器的 80 端口。
Flags [S] 则表示这是一个 SYN 包
3.使用tcpdump抓取eth0上的包
YN Flood (SYN洪水) 是种典型的DoS (Denial of Service，拒绝服务) 攻击。效果就是服务器TCP连接资源耗尽，停止响应正常的TCP连接请求。
结合sar发现的PPS 超过 12000 以及接收到的包是SYN包的现象，可以确认，这就是从 192.168.0.2 这个地址发送过来的 SYN FLOOD 攻击
SYN FLOOD 问题最简单的解决方法，就是从交换机或者硬件防火墙中封掉来源 IP，这样 SYN FLOOD 网络帧就不会发送到服务器中。
4.确认问题
第10讲，软中断排查案例
用户 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 时间百分比。
CPU使用率
平均负载（Load Average）
无法获取资源而导致的自愿上下文切换
被系统强制调度导致的非自愿上下文切换
CPU 缓存的速度介于 CPU 和内存之间，缓存的是热点的内存数据。根据不断增长的热点数据，这些缓存按照大小不同分为 L1、L2、L3 等三级缓存，其中 L1 和 L2 常用在单核中， L3 则用在多核中。从 L1 到 L3，三级缓存的大小依次增大，相应的，性能依次降低（当然比内存还是好得多）。而它们的命中率，衡量的是 CPU 缓存的复用情况，命中率越高，则表示性能越好。
CPU 缓存的命中率
CPU性能指标
第一个维度，从 CPU 的性能指标出发。也就是说，当你要查看某个性能指标时，要清楚知道哪些工具可以做到。
第二个维度，从工具出发。也就是当你已经安装了某个工具后，要知道这个工具能提供哪些指标。
分析思路的两个维度
把所有的指标都查出来再统一分析=》这种方法的效率真的太低了！耗时耗力不说，在庞大的指标体系面前，你一不小心可能就忽略了某个细节，导致白干一场
pidstat 输出的进程用户 CPU 使用率升高，会导致 top 输出的用户 CPU 使用率升高。所以，当发现 top 输出的用户 CPU 使用率有问题时，可以跟 pidstat 的输出做对比，观察是否是某个进程导致的问题。而找出导致性能问题的进程后，就要用进程分析工具来分析进程的行为，比如使用 strace 分析系统调用情况，以及使用 perf 分析调用链中各级函数的执行情况
如果是不可中断进程数增多了，那么就需要做 I/O 的分析，也就是用 dstat 或 sar 等工具，进一步分析 I/O 的情况
如果是运行状态进程数增多了，那就需要回到 top 和 pidstat，找出这些处于运行状态的到底是什么进程，然后再用进程分析工具，做进一步分
第二个例子，top 输出的平均负载升高，可以跟 vmstat 输出的运行状态和不可中断状态的进程数做对比，观察是哪种进程导致的负载升高。
最后一个例子，当发现 top 输出的软中断 CPU 使用率升高时，可以查看 /proc/softirqs 文件中各种类型软中断的变化情况，确定到底是哪种软中断出的问题。比如，发现是网络接收中断导致的问题，那就可以继续用网络分析工具 sar 和 tcpdump 来分析
这三个工具输出的很多指标是相互关联的，所以图中用虚线表示了它们的关联关系。举例子
缩小排查范围，我通常会先运行几个支持指标较多的工具，如 top、vmstat 和 pidstat
如何迅速分析 CPU 的性能瓶颈？
第11讲，快速分析cpu瓶颈（分析总结篇）
好的应用程序是性能优化的最终目的和结果，系统优化总是为应用程序服务的。所以，必须要使用应用程序的指标，来评估性能优化的整体效果
应用程序的维度，我们可以用吞吐量和请求延迟来评估应用程序的性能
系统资源的使用情况是影响应用程序性能的根源。所以，需要用系统资源的指标，来观察和分析瓶颈的来源
系统资源的维度，我们可以用 CPU 使用率来评估系统的 CPU 使用情况
比如，以 Web 应用为例：
不要局限在单一维度的指标上，你至少要从应用程序和系统资源这两个维度，分别选择不同的指标。
确定性能的量化指标。
测试优化前的性能指标
测试优化后的性能指标
第一，要避免性能测试工具干扰应用程序的性能。通常，对 Web 应用来说，性能测试工具跟目标应用程序要在不同的机器上运行
第二，避免外部环境的变化影响性能指标的评估。这要求优化前、后的应用程序，都运行在相同配置的机器上，并且它们的外部依赖也要完全一致。
测试时注意事项（上面后两项）
怎么评估性能优化的效果？
首先，既然要做性能优化，那要怎么判断它是不是有效呢？特别是优化后，到底能提升多少性能呢？
动手优化之前先动脑，先把所有这些性能问题给分析一遍，找出最重要的、可以最大程度提升性能的问题，从它开始优化。这样的好处是，不仅性能提升的收益最大，而且很可能其他问题都不用优化，就已经满足了性能要求。
第一，如果发现是系统资源达到了瓶颈，比如 CPU 使用率达到了 100%，那么首先优化的一定是系统资源使用问题。完成系统资源瓶颈的优化后，我们才要考虑其他问题。
第二，针对不同类型的指标，首先去优化那些由瓶颈导致的，性能指标变化幅度最大的问题。比如产生瓶颈后，用户 CPU 使用率升高了 10%，而系统 CPU 使用率却升高了 50%，这个时候就应该首先优化系统 CPU 的使用
怎么判断出哪个性能问题最重要？（简化版）
第二，性能问题通常不是独立的，如果有多个性能问题同时发生，你应该先优化哪一个呢？
不要想着“一步登天”，试图一次性解决所有问题；
也不要只会“拿来主义”，把其他应用的优化方法原封不动拿来用，却不经过任何思考和分析。
性能优化并非没有成本。性能优化通常会带来复杂度的提升，降低程序的可维护性，还可能在优化一个指标时，引发其他指标的异常。也就是说，很可能你优化了一个指标，另一个指标的性能却变差了。
第三，提升性能的方法并不是唯一的，当有多种方法可以选择时，你会选用哪一种呢？是不是总选那个最大程度提升性能的方法就行了呢？
优化三问题
编译器优化：很多编译器都会提供优化选项，适当开启它们，在编译阶段你就可以获得编译器的帮助，来提升性能。比如， gcc 就提供了优化选项 -O2，开启后会自动对应用程序的代码进行优化。
算法优化：使用复杂度更低的算法，可以显著加快处理速度。比如，在数据比较大的情况下，可以用 O(nlogn) 的排序算法（如快排、归并排序等），代替 O(n^2) 的排序算法（如冒泡、插入排序等）
异步处理：使用异步处理，可以避免程序因为等待某个资源而一直阻塞，从而提升程序的并发处理能力。比如，把轮询替换为事件通知，就可以避免轮询耗费 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 上
系统维度
常见的优化方式
一方面，优化会带来复杂性的提升，降低可维护性；另一方面，需求不是一成不变的。针对当前情况进行的优化，很可能并不适应快速变化的新需求。这样，在新需求出现时，这些复杂的优化，反而可能阻碍新功能的开发。
避免过早优化
第12讲，CPU性能优化的几个思路（优化总结篇）
CPU篇
Linux 内核给每个进程都提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样，进程就可以很方便地访问内存，更确切地说是访问虚拟内存
进程在用户态时，只能访问用户空间内存；只有进入内核态后，才可以访问内核空间内存。虽然每个进程的地址空间都包含了内核空间，但这些内核空间，其实关联的都是相同的物理内存。这样，进程切换到内核态后，就可以很方便地访问内核空间内存
虚拟地址空间的内部又被分为内核空间和用户空间两部分，不同字长（也就是单个 CPU 指令可以处理数据的最大长度）的处理器，地址空间的范围也不同
页表实际上存储在 CPU 的内存管理单元 MMU 中，这样，正常情况下，处理器就可以直接通过硬件，找出要访问的内存。而当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存、更新进程页表，最后再返回用户空间，恢复进程的运行
Linux 通过 TLB（Translation Lookaside Buffer）来管理虚拟内存到物理内存的映射关系。当虚拟内存更新后，TLB 也需要刷新，内存的访问也会随之变慢
TLB 其实就是 MMU 中页表的高速缓存。由于进程的虚拟地址空间是独立的，而 TLB 的访问速度又比 MMU 快得多，所以，通过减少进程的上下文切换，减少 TLB 的刷新次数，就可以提高 TLB 缓存的使用率，进而提高 CPU 的内存访问性能。
解答第三讲为什么进程上下文切换会影响CPU性能？
并不是所有的虚拟内存都会分配物理内存，只有那些实际使用的虚拟内存才分配物理内存，并且分配后的物理内存，是通过内存映射来管理的。为了完成内存映射，内核为每个进程都维护了一张页表，记录虚拟地址与物理地址的映射关系
内存映射
内核空间
只读段，包括代码和常量等
数据段，包括全局变量等
堆，包括动态分配的内存，从低地址开始向上增长
文件映射段，包括动态库、共享内存等，从高地址开始向下增长
栈，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB
32位系统的图
虚拟内存空间分布
可以减少缺页异常的发生，提高内存访问效率。不过，由于这些内存没有归还系统，在内存工作繁忙时，频繁的内存分配和释放会造成内存碎片。
对小块内存（小于 128K），C 标准库使用 brk() 来分配，也就是通过移动堆顶的位置来分配内存。这些内存释放后并不会立刻归还系统，而是被缓存起来，这样就可以重复使用
而 mmap() 方式分配的内存，会在释放时直接归还系统，所以每次 mmap 都会发生缺页异常。在内存工作繁忙时，频繁的内存分配会导致大量的缺页异常，使内核的管理负担增大。这也是 malloc 只对大块内存使用 mmap 的原因。
对于大块内存（大于 128K），则直接使用内存映射 mmap() 来分配，也就是在文件映射段找一块空闲内存分配出去。
了解这两种调用方式后，我们还需要清楚一点，那就是，当这两种调用发生后，其实并没有真正分配内存。这些内存，都只在首次访问时才分配，也就是通过缺页异常进入内核中，再由内核来分配内存
所以，在用户空间，malloc 通过 brk() 分配的内存，在释放时并不立即归还系统，而是缓存起来重复利用。在内核空间，Linux 则通过 slab 分配器来管理小内存。你可以把 slab 看成构建在伙伴系统上的一个缓存，主要作用就是分配并释放内核中的小对象
实际系统运行中，确实有大量比页还小的对象，如果为它们也分配单独的页，那就太浪费内存了。
内存的分配
回收缓存，比如使用 LRU（Least Recently Used）算法，回收最近使用最少的内存页面；
会用到交换分区（以下简称 Swap）。Swap 其实就是把一块磁盘空间当成内存来用。它可以把进程暂时不用的数据存储到磁盘中（这个过程称为换出），当进程访问这些内存时，再从磁盘读取这些数据到内存中（这个过程称为换入）。
通常只在内存不足时，才会发生 Swap 交换。并且由于磁盘读写的速度远比内存慢，Swap 会导致严重的内存性能问题。
回收不常访问的内存，把不常用的内存通过交换分区直接写到磁盘中；
一个进程消耗的内存越大，oom_score 就越大
一个进程运行占用的 CPU 越多，oom_score 就越小。
比如用下面的命令，你就可以把 sshd 进程的 oom_adj 调小为 -16，这样， sshd 进程就不容易被 OOM 杀死。
echo -16 > /proc/$(pidof sshd)/oom_adj
为了实际工作的需要，管理员可以通过 /proc 文件系统，手动设置进程的 oom_adj ，从而调整进程的 oom_score
杀死进程，内存紧张时系统还会通过 OOM（Out of Memory），直接杀掉占用大量内存的进程
在发现内存紧张时，系统就会通过一系列机制来回收内存，比如下面这三种方式：
内存的回收
理论知识
第一列，total 是总内存大小
第二列，used 是已使用内存的大小，包含了共享内存
第三列，free 是未使用内存的大小
第四列，shared 是共享内存的大小
第五列，buff/cache 是缓存和缓冲区的大小(总合)；
available 不仅包含未使用内存，还包括了可回收的缓存，所以一般会比未使用内存更大。不过，并不是所有缓存都可以回收，因为有些缓存可能正在使用中。
最后一列，available 是新进程可用内存的大小
# 注意不同版本的free输出可能会有所不同$ free total used free shared buff/cache availableMem: 8169348 263524 6875352 668 1030472 7611064Swap: 0 0 0
free 输出的是一个表格，其中的数值都默认以字节为单位。表格总共有两行六列，这两行分别是物理内存 Mem 和交换分区 Swap 的使用情况
free命令或top命令查看整体情况
VIRT 是进程虚拟内存的大小，只要是进程申请过的内存，即便还没有真正分配物理内存，也会计算在内
RES 是常驻内存的大小，也就是进程实际使用的物理内存大小，但不包括 Swap 和共享内存。
SHR 是共享内存的大小，比如与其他进程共同使用的共享内存、加载的动态链接库以及程序的代码段
%MEM 是进程使用物理内存占系统总内存的百分比
第一，虚拟内存通常并不会全部分配物理内存。从上面的输出，你可以发现每个进程的虚拟内存都比常驻内存大得多
第二，共享内存 SHR 并不一定是共享的，比方说，程序的代码段、非共享的动态链接库，也都算在 SHR 里。当然，SHR 也包括了进程间真正共享的内存。所以在计算多个进程的内存使用时，不要把所有进程的 SHR 直接相加得出结果
在查看 top 输出时，你还要注意两点
使用top或ps查看进程的内存使用情况
查看内存使用情况
第15讲 内存基础简介
Buffer 既可以用作“将要写入磁盘数据的缓存”，也可以用作“从磁盘读取数据的缓存
Buffers 是对原始磁盘块的临时存储，也就是用来缓存磁盘的数据，通常不会特别大（20MB 左右）。这样，内核就可以把分散的写集中起来，统一优化磁盘的写入，比如可以把多次小的写合并成单次大的写等等
Buffers 是内核缓冲区用到的内存，对应的是 /proc/meminfo 中的 Buffers 值
Cache 既可以用作“从文件读取数据的页缓存”，也可以用作“写文件的页缓存”
Cached 是从磁盘读取文件的页缓存，也就是用来缓存从文件读取的数据。这样，下次访问这些文件数据时，就可以直接从内存中快速获取，而不需要再次访问缓慢的磁盘
SReclaimable 是 Slab 的一部分。Slab 包括两部分，其中的可回收部分，用 SReclaimable 记录；而不可回收部分，用 SUnreclaim 记录
Cache 是内核页缓存和 Slab 用到的内存，对应的是 /proc/meminfo 中的 Cached 与 SReclaimable 之和
含义：free命令中的buff/cache一列
Buffer 是对磁盘数据的缓存，而 Cache 是文件数据的缓存，它们既会用在读请求中，也会用在写请求中
磁盘是一个块设备，可以划分为不同的分区；在分区之上再创建文件系统，挂载到某个目录，之后才可以在这个目录中读写文件。其实 Linux 中“一切皆文件”，而文章中提到的“文件”是普通文件，磁盘是块设备文件，这些大家可以执行 \"ls -l <路径>\" 查看它们的区别（输出的含义如果不懂请 man ls 查询）。在读写普通文件时，会经过文件系统，由文件系统负责与磁盘交互；而读写磁盘或者分区时，就会跳过文件系统，也就是所谓的“裸I/O“。这两种读写方式所使用的缓存是不同的，也就是文中所讲的 Cache 和 Buffer 区别
磁盘与文件区别
总结
第16讲，理解内存的buffer和cache
下面就是一个 cachestat 的运行界面，它以 1 秒的时间间隔，输出了 3 组缓存统计数据$ cachestat 1 3TOTAL MISSES HITS DIRTIES BUFFERS_MB CACHED_MB2 0 2 1 17 2792 0 2 1 17 2792 0 2 1 17 279
cachestat 提供了整个操作系统缓存的读写命中情况
$ cachetop11:58:50 Buffers MB: 258 / Cached MB: 347 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 13029 root python 1 0 0 100.0% 0.0%
cachetop 工具并不把直接 I/O 算进来
cachetop 提供了每个进程的缓存命中情况
TOTAL ，表示总的 I/O 次数
MISSES ，表示缓存未命中的次数；
HITS ，表示缓存命中的次数
DIRTIES， 表示新增到缓存中的脏页数
BUFFERS_MB 表示 Buffers 的大小，以 MB 为单位
CACHED_MB 表示 Cache 的大小，以 MB 为单位
cachestat和cachetop 的列解释
$ pcstat /bin/ls+---------+----------------+------------+-----------+---------+| Name | Size (bytes) | Pages | Cached | Percent ||---------+----------------+------------+-----------+---------|| /bin/ls | 133792 | 33 | 0 | 000.000 |+---------+----------------+------------+-----------+---------+
pcstat来查看文件在内存中的缓存大小以及缓存比例。
新学工具命令
第17讲案例篇：如何利用系统缓存优化程序的运行效率
# 每隔3秒输出一组数据$ vmstat 3procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa stprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 6601824 97620 1098784 0 0 0 0 62 322 0 0 100 0 00 0 0 6601700 97620 1098788 0 0 0 0 57 251 0 0 100 0 00 0 0 6601320 97620 1098788 0 0 0 3 52 306 0 0 100 0 00 0 0 6601452 97628 1098788 0 0 0 27 63 326 0 0 100 0 02 0 0 6601328 97628 1098788 0 0 0 44 52 299 0 0 100 0 00 0 0 6601080 97628 1098792 0 0 0 0 56 285 0 0 100 0 0
使用vmstat确认系统内存是否不断减少
使用memleak来确认进程是否内存泄露
第18讲，定位内存泄露（题外话：其实对于判断进程是否内存泄露，还是自己搭建好监控系统来判断更好，本小节对我比较有用是可以定位到堆栈，当看代码排查不出时，这很有用）
文件页：缓存和缓冲区，就属于可回收内存（cache和buffer）
匿名页: 应用程序动态分配的堆内存，也就是我们在内存管理中说到的匿名页
名词
所谓换出，就是把进程暂时不用的内存数据存储到磁盘中，并释放这些数据占用的内存
而换入，则是在进程再次访问这些内存的时候，把它们从磁盘读到内存中来
原理简介：Swap 说白了就是把一块磁盘空间或者一个本地文件（以下讲解以磁盘为例），当成内存来使用。它包括换出和换入两个过程
直接内存回收：有新的大块内存分配请求，但是剩余内存不足。这个时候系统就需要回收一部分内存（比如前面提到的缓存），进而尽可能地满足新内存请求
这个页低阈值，其实可以通过内核选项 /proc/sys/vm/min_free_kbytes 来间接设置
余内存小于页最小阈值，说明进程可用内存都耗尽了，只有内核才可以分配内存
剩余内存落在页最小阈值和页低阈值中间，说明内存压力比较大，剩余内存不多了。这时 kswapd0 会执行内存回收，直到剩余内存大于高阈值为止
剩余内存落在页低阈值和页高阈值中间，说明内存有一定压力，但还可以满足新内存请求
剩余内存大于页高阈值，说明剩余内存比较多，没有内存压力
kswapd0，一个专门的内核线程用来定定期扫描内存的使用情况，并根据剩余内存落在这三个阈值的空间位置，进行内存的回收操作
swap回收场景
可能导致问题：你明明发现了 Swap 升高，可是在分析系统的内存使用时，却很可能发现，系统剩余内存还多着呢。
在 NUMA 架构下，多个处理器被划分到不同 Node 上，且每个 Node 都拥有自己的本地内存空间。而同一个 Node 内部的内存空间，实际上又可以进一步分为不同的内存域（Zone），比如直接内存访问区（DMA）、普通内存区（NORMAL）、伪内存区（MOVABLE）等
默认的 0 ，也就是刚刚提到的模式，表示既可以从其他 Node 寻找空闲内存，也可以从本地回收内存。
1、2、4 都表示只回收本地内存，2 表示可以回写脏数据回收内存，4 表示可以用 Swap 方式回收内存。
某个 Node 内存不足时，系统可以从其他 Node 寻找空闲内存，也可以从本地内存中回收内存（swap升高，但系统剩余内存多的原因）。具体选哪种模式，你可以通过 /proc/sys/vm/zone_reclaim_mode 来调整。它支持以下几个选项：
NUMA （Non-Uniform Memory Access）架构
对文件页的回收，当然就是直接回收缓存，或者把脏页写回磁盘后再回收。
而对匿名页的回收，其实就是通过 Swap 机制，把它们写入磁盘后再释放内存。
回收方式
swappiness 的范围是 0-100，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页；数值越小，越消极使用 Swap，也就是更倾向于回收文件页
不过要注意，这并不是内存的百分比，而是调整 Swap 积极程度的权重，即使你把它设置成 0，当剩余内存 + 文件页小于页高阈值时，还是会发生 Swap。
/proc/sys/vm/swappiness 选项，用来调整使用 Swap 的积极程度
swap回收的内存既包括了文件页，又包括了匿名页
swappiness
评论知识点：绝大部分 Java 的应用都建议关 swap，这个和 JVM 的 gc 有关，它在 gc 的时候会遍历所有用到的堆的内存，如果这部分内存是被 swap 出去了，遍历的时候就会有磁盘IO
第19讲，swap原理知识
开启swap
# 写入空设备，实际上只有磁盘的读请求$ dd if=/dev/sda1 of=/dev/null bs=1G count=2048
模拟大文件的读取
sar 的输出结果是两个表格，第一个表格表示内存的使用情况，第二个表格表示 Swap 的使用情况。其中，各个指标名称前面的 kb 前缀，表示这些指标的单位是 KB。
kbcommit，表示当前系统负载需要的内存。它实际上是为了保证系统内存不溢出，对需要内存的估计值。%commit，就是这个值相对总内存的百分比。
kbactive，表示活跃内存，也就是最近使用过的内存，一般不会被系统回收。
kbinact，表示非活跃内存，也就是不常访问的内存，有可能会被系统回收
# 间隔1秒输出一组数据# -r表示显示内存使用情况，-S表示显示Swap使用情况$ sar -r -S 104:39:56 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty04:39:57 6249676 6839824 1919632 23.50 740512 67316 1691736 10.22 815156 841868 404:39:56 kbswpfree kbswpused %swpused kbswpcad %swpcad04:39:57 8388604 0 0.00 0 0.0004:39:57 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty04:39:58 6184472 6807064 1984836 24.30 772768 67380 1691736 10.22 847932 874224 2004:39:57 kbswpfree kbswpused %swpused kbswpcad %swpcad04:39:58 8388604 0 0.00 0 0.00…04:44:06 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty04:44:07 152780 6525716 8016528 98.13 6530440 51316 1691736 10.22 867124 6869332 004:44:06 kbswpfree kbswpused %swpused kbswpcad %swpcad04:44:07 8384508 4096 0.05 52 1.27
总结：1.刚开始，剩余内存（kbmemfree）不断减少，而缓冲区（kbbuffers）则不断增大，由此可知，剩余内存不断分配给了缓冲区。2.一段时间后，剩余内存已经很小，而缓冲区占用了大部分内存。这时候，Swap 的使用开始逐渐增大，缓冲区和剩余内存则只在小范围内波动
使用sar命令观察内存各个指标的变化
环境部署：
$ cachetop 512:28:28 Buffers MB: 6349 / Cached MB: 87 / Sort: HITS / Order: ascendingPID UID CMD HITS MISSES DIRTIES READ_HIT% WRITE_HIT% 18280 root python 22 0 0 100.0% 0.0% 18279 root dd 41088 41022 0 50.0% 50.0%
dd 进程的读写请求只有 50% 的命中率，并且未命中的缓存页数（MISSES）为 41022（单位是页）。这说明，正是案例开始时运行的 dd，导致了缓冲区使用升高。
1.为什么缓冲区在增大，哪个进程导致?使用cachetop命令查看
，剩余内存（pages_free）在一个小范围内不停地波动。当它小于页低阈值（pages_low) 时，又会突然增大到一个大于页高阈值（pages_high）的值
再结合刚刚用 sar 看到的剩余内存和缓冲区的变化情况，我们可以推导出，剩余内存和缓冲区的波动变化，正是由于内存回收和缓存再次分配的循环往复。
当剩余内存小于页低阈值时，系统会回收一些缓存和匿名内存，使剩余内存增大。其中，缓存的回收导致 sar 中的缓冲区减小，而匿名内存的回收导致了 Swap 的使用增大。紧接着，由于 dd 还在继续，剩余内存又会重新分配给缓存，导致剩余内存减少，缓冲区增大。
通过 /proc/zoneinfo ，观察剩余内存、内存阈值以及匿名页和文件页的活跃情况
2.为什么swap也跟着升高？直观来说，缓冲区占了系统绝大部分内存，还属于可回收内存，内存不够用时，不应该先回收缓冲区吗？
# 按VmSwap使用量对进程排序，输出进程名称、进程ID以及SWAP用量$ for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 \" \" $3}END{ print \"\"}' $file; done | sort -k 3 -n -r | headdockerd 2226 10728 kBdocker-containe 2251 8516 kBsnapd 936 4020 kBnetworkd-dispat 911 836 kBpolkitd 1004 44 kB
第一种方式：查看/proc/pid/status 中的 VmSwap （推荐你执行 man proc 来查询其他字段的含义）
第二种方式：用smem --sort swap命令可以直接将进程按照swap使用量排序显示
3.刚才的 Swap 到底影响了哪些应用程序呢？换句话说，Swap 换出的是哪些进程的内存？
问题排查：
案例：
Swap 变高时，你可以用 sar、/proc/zoneinfo、/proc/pid/status 等方法，查看系统和进程的内存使用情况，进而找出 Swap 升高的根源和受影响的进程。反过来说，通常，降低 Swap 的使用，可以提高系统的整体性能。
禁止 Swap，现在服务器的内存足够大，所以除非有必要，禁用 Swap 就可以了。随着云计算的普及，大部分云平台中的虚拟机都默认禁止 Swap。
如果实在需要用到 Swap，可以尝试降低 swappiness 的值，减少内存回收时 Swap 的使用倾向。
响应延迟敏感的应用，如果它们可能在开启 Swap 的服务器中运行，你还可以用库函数 mlock() 或者 mlockall() 锁定内存，阻止它们的内存换出。
几种常见的降低swap方法
小结：
第20讲，swap案例分析
已用内存
剩余内存
可用内存是新进程可以使用的最大内存，它包括剩余内存和可回收缓存
可用内存
需要磁盘 I/O 介入（比如 Swap）
主缺页异常
可以直接从物理内存中分配时
次缺页异常
缺页异常
使用量
命中率
缓存/缓冲区
SLABS
系统内存指标
包括了进程代码段、数据段、共享内存、已经申请的堆内存和已经换出的内存等。这里要注意，已经申请的内存，即使还没有分配物理内存，也算作虚拟内存。
虚拟内存（VSS）
常驻内存是进程实际使用的物理内存，不过，它不包括 Swap 和共享内存
常驻内存(RSS)
按比例分配共享内存后的物理内存(PSS)
独占内存(USS)
既包括与其他进程共同使用的真实的共享内存，还包括了加载的动态链接库以及程序的代码段等。
共享内存
SWAP内存
进程内存指标
已用空间
剩余空间
换入速度
换出速度
SWAP
内存性能指标
根据指标选择工具
知道各个工具可以看什么指标
先用 free 和 top，查看系统整体的内存使用情况。
再用 vmstat 和 pidstat，查看一段时间的趋势，从而判断出内存问题的类型。
最后进行详细分析，比如内存分配分析、缓存 / 缓冲区分析、具体进程的内存使用分析等。
第一个例子，当你通过 free，发现大部分内存都被缓存占用后，可以使用 vmstat 或者 sar 观察一下缓存的变化趋势，确认缓存的使用是否还在继续增大。如果继续增大，则说明导致缓存升高的进程还在运行，那你就能用缓存 / 缓冲区分析工具（比如 cachetop、slabtop 等），分析这些缓存到底被哪里占用。
第二个例子，当你 free 一下，发现系统可用内存不足时，首先要确认内存是否被缓存 / 缓冲区占用。排除缓存 / 缓冲区后，你可以继续用 pidstat 或者 top，定位占用内存最多的进程。找出进程后，再通过进程内存空间工具（比如 pmap），分析进程地址空间中内存的使用情况就可以了。
第三个例子，当你通过 vmstat 或者 sar 发现内存在不断增长后，可以分析中是否存在内存泄漏的问题。比如你可以使用内存分配分析工具 memleak ，检查是否存在内存泄漏。如果存在内存泄漏问题，memleak 会为你输出内存泄漏的进程以及调用堆栈。
举例子
如何快速分析内存的性能瓶颈（常规）
最好禁止 Swap。如果必须开启 Swap，降低 swappiness 的值，减少内存回收时 Swap 的使用倾向
减少内存的动态分配。比如，可以使用内存池、大页（HugePage）等。
尽量使用缓存和缓冲区来访问数据。比如，可以使用堆栈明确声明内存空间，来存储需要缓存的数据；或者用 Redis 这类的外部缓存组件，优化数据的访问
使用 cgroups 等方式限制进程的内存使用情况。这样，可以确保系统内存不会被异常进程耗尽
通过 /proc/pid/oom_adj ，调整核心应用的 oom_score。这样，可以保证即使内存紧张，核心应用也不会被 OOM 杀死
常见的优化思路
第21讲，套路总结
内存篇
简称为 dentry，用来记录文件的名字、索引节点指针以及与其他目录项的关联关系。多个关联的目录项，就构成了文件系统的目录结构。不过，不同于索引节点，目录项是由内核维护的一个内存数据结构，所以通常也被叫做目录项缓存。
目录项（注意是内存）
简称为 inode，用来记录文件的元数据，比如 inode 编号、文件大小、访问权限、修改日期、数据的位置等。索引节点和文件一一对应，它跟文件内容一样，都会被持久化存储到磁盘中。所以记住，索引节点同样占用磁盘空间
索引节点
可以有多个逻辑块，每个逻辑块由多个扇区组成
数据块
每个文件由三部分组成
超级块，存储整个文件系统的状态
索引节点区，用来存储索引节点
数据块区，则用来存储文件数据
磁盘在执行文件系统格式化时，会被分成三个存储区域
图解释
目录项、索引节点、逻辑块以及超级块，构成了 Linux 文件系统的四大基本要素。不过，为了支持各种不同的文件系统，Linux 内核在用户进程和文件系统的中间，又引入了一个抽象层，也就是虚拟文件系统 VFS。VFS 定义了一组所有文件系统都支持的数据结构和标准接口。这样，用户进程和内核中的其他子系统，只需要跟 VFS 提供的统一接口进行交互就可以了，而不需要再关心底层各种文件系统的实现细节。
图解
第一类是基于磁盘的文件系统，也就是把数据直接存储在计算机本地挂载的磁盘中。常见的 Ext4、XFS、OverlayFS 等，都是这类文件系统
第二类是基于内存的文件系统，也就是我们常说的虚拟文件系统。这类文件系统，不需要任何磁盘分配存储空间，但会占用内存。我们经常用到的 /proc 文件系统，其实就是一种最常见的虚拟文件系统。此外，/sys 文件系统也属于这一类，主要向用户空间导出层次化的内核对象。
第三类是网络文件系统，也就是用来访问其他计算机数据的文件系统，比如 NFS、SMB、iSCSI 等
图中文件系统可以分为三类
文件系统要先挂载到 VFS 目录树中的某个子目录（称为挂载点），然后才能访问其中的文件。
虚拟文件系统VFS
缓冲 I/O，是指利用标准库缓存来加速文件的访问，而标准库内部再通过系统调度访问文件。
非缓冲 I/O，是指直接通过系统调用来访问文件，不再经过标准库缓存。
第一种，根据是否利用标准库缓存，可以把文件 I/O 分为缓冲 I/O 与非缓冲 I/O
直接 I/O，是指跳过操作系统的页缓存，直接跟文件系统交互来访问文件
非直接 I/O 正好相反，文件读写时，先要经过系统的页缓存，然后再由内核或额外的系统调用，真正写入磁盘。
直接 I/O、非直接 I/O，本质上还是和文件系统交互。如果是在数据库等场景中，你还会看到，跳过文件系统读写磁盘的情况，也就是我们通常所说的裸 I/O。
第二，根据是否利用操作系统的页缓存，可以把文件 I/O 分为直接 I/O 与非直接 I/O
所谓阻塞 I/O，是指应用程序执行 I/O 操作后，如果没有获得响应，就会阻塞当前线程，自然就不能执行其他任务
所谓非阻塞 I/O，是指应用程序执行 I/O 操作后，不会阻塞当前的线程，可以继续执行其他的任务，随后再通过轮询或者事件通知的形式，获取调用的结果。
第三，根据应用程序是否阻塞自身运行，可以把文件 I/O 分为阻塞 I/O 和非阻塞 I/O
所谓同步 I/O，是指应用程序执行 I/O 操作后，要一直等到整个 I/O 完成后，才能获得 I/O 响应
所谓异步 I/O，是指应用程序执行 I/O 操作后，不用等待完成和完成后的响应，而是继续执行就可以。等到这次 I/O 完成后，响应会用事件通知的方式，告诉应用程序
第四，根据是否等待响应结果，可以把文件 I/O 分为同步和异步 I/O
文件io的分类维度
有时候碰到了空间不足的问题，可是用 df 查看磁盘空间后，却发现剩余空间还有很多，是因为除了文件数据，索引节点也占用磁盘空间，有可能小文件过多导致索引节点用光了，此时可以使用df -i来查看索引节点使用情况，
df -h命令能查看文件系统的磁盘空间使用情况
容量
free 输出的 Cache，是页缓存和可回收 Slab 缓存的和
可以用 free 或 vmstat，来观察页缓存的大小
$ cat /proc/slabinfo | grep -E '^#|dentry|inode' # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> xfs_inode 0 0 960 17 4 : tunables 0 0 0 : slabdata 0 0 0 ... ext4_inode_cache 32104 34590 1088 15 4 : tunables 0 0 0 : slabdata 2306 2306 0hugetlbfs_inode_cache 13 13 624 13 2 : tunables 0 0 0 : slabdata 1 1 0 sock_inode_cache 1190 1242 704 23 4 : tunables 0 0 0 : slabdata 54 54 0 shmem_inode_cache 1622 2139 712 23 4 : tunables 0 0 0 : slabdata 93 93 0 proc_inode_cache 3560 4080 680 12 2 : tunables 0 0 0 : slabdata 340 340 0 inode_cache 25172 25818 608 13 2 : tunables 0 0 0 : slabdata 1986 1986 0 dentry 76050 121296 192 21 1 : tunables 0 0 0 : slabdata 5776 5776 0
dentry 行表示目录项缓存，inode_cache 行，表示 VFS 索引节点缓存，其余的则是各种文件系统的索引节点缓存。
/proc/slabinfo 的列比较多，具体含义你可以查询 man slabinfo。在实际性能分析中，我们更常使用 slabtop ，来找到占用内存最多的缓存类型。
目录项和索引节点缓存
缓存
性能观测
第23讲，linux文件系统
对机械磁盘来说，由于随机 I/O 需要更多的磁头寻道和盘片旋转 ，它的性能自然要比连续 I/O 慢
对固态磁盘来说，虽然它的随机性能比机械硬盘好很多，但同样存在“先擦除再写入”的限制。随机读写会导致大量的垃圾回收，所以相对应的，随机 I/O 的性能比起连续 I/O 来，也还是差了很多。
此外，连续 I/O 还可以通过预读的方式，来减少 I/O 请求的次数，这也是其性能优异的一个原因。很多性能优化的方案，也都会从这个角度出发，来优化 I/O 性能。
无论机械磁盘，还是固态磁盘，相同磁盘的随机 I/O 都要比连续 I/O 慢很多
机械磁盘的最小读写单位是扇区，一般大小为 512 字节
而固态磁盘的最小读写单位是页，通常大小是 4KB、8KB 等
如果每次都读写 512 字节这么小的单位的话，效率很低。所以文件系统会把连续的扇区或页，组成逻辑块，然后以逻辑块作为最小单元来管理数据。常见的逻辑块的大小是 4KB，也就是说，连续 8 个扇区，或者单独的一个页，都可以组成一个逻辑块。
第一个功能跟虚拟文件系统的功能类似。向上，为文件系统和应用程序，提供访问块设备的标准接口；向下，把各种异构的磁盘设备抽象为统一的块设备，并提供统一框架来管理这些设备的驱动程序
第一种 NONE ，更确切来说，并不能算 I/O 调度算法。因为它完全不使用任何 I/O 调度器，对文件系统和应用程序的 I/O 其实不做任何处理，常用在虚拟机中（此时磁盘 I/O 调度完全由物理机负责）。
第二种 NOOP ，是最简单的一种 I/O 调度算法。它实际上是一个先入先出的队列，只做一些最基本的请求合并，常用于 SSD 磁盘
第三种 CFQ（Completely Fair Scheduler），也被称为完全公平调度器，是现在很多发行版的默认 I/O 调度器，它为每个进程维护了一个 I/O 调度队列，并按照时间片来均匀分布每个进程的 I/O 请求。类似于进程 CPU 调度，CFQ 还支持进程 I/O 的优先级调度，所以它适用于运行大量进程的系统，像是桌面环境、多媒体应用等
最后一种 DeadLine 调度算法，分别为读、写请求创建了不同的 I/O 队列，可以提高机械磁盘的吞吐量，并确保达到最终期限（deadline）的请求被优先处理。DeadLine 调度算法，多用在 I/O 压力比较重的场景，比如数据库等。
第二个功能，通用块层还会给文件系统和应用程序发来的 I/O 请求排队，并通过重新排序、请求合并等方式，提高磁盘读写的效率。
为了减小不同块设备的差异带来的影响，Linux 通过一个统一的通用块层，来管理各种不同的块设备.它主要有两个功能
通用块层
文件系统层，包括虚拟文件系统和其他各种文件系统的具体实现。它为上层的应用程序，提供标准的文件访问接口；对下会通过通用块层，来存储和管理磁盘数据
通用块层，包括块设备 I/O 队列和 I/O 调度器。它会对文件系统的 I/O 请求进行排队，再通过重新排序和请求合并，然后才要发送给下一级的设备层
设备层，包括存储设备和相应的驱动程序，负责最终物理设备的 I/O 操作
全景图
I/O 栈的全景
使用率只考虑有没有 I/O，而不考虑 I/O 的大小。换句话说，当使用率是 100% 的时候，磁盘依然有可能接受新的 I/O 请求
使用率，是指磁盘处理 I/O 的时间百分比。过高的使用率（比如超过 80%），通常意味着磁盘 I/O 存在性能瓶颈。
饱和度，是指磁盘处理 I/O 的繁忙程度。过高的饱和度，意味着磁盘存在严重的性能瓶颈。当饱和度为 100% 时，磁盘无法接受新的 I/O 请求
IOPS（Input/Output Per Second），是指每秒的 I/O 请求数（请求次数）。
吞吐量，是指每秒的 I/O 请求大小
响应时间，是指 I/O 请求从发出到收到响应的间隔时间
磁盘性能指标
# -d -x表示显示所有磁盘I/O的指标$ iostat -d -x 1 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 loop1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
这些指标中，你要注意：%util ，就是我们前面提到的磁盘 I/O 使用率；r/s+ w/s ，就是 IOPS；rkB/s+wkB/s ，就是吞吐量；r_await+w_await ，就是响应时间。
iostat 是最常用的磁盘 I/O 性能观测工具，它提供了每个磁盘的使用率、IOPS、吞吐量等各种常见的性能指标，当然，这些指标实际上来自 /proc/diskstats
用户 ID（UID）和进程 ID（PID）
每秒读取的数据大小（kB_rd/s） ，单位是 KB
每秒发出的写请求数据大小（kB_wr/s） ，单位是 KB
每秒取消的写请求数据大小（kB_ccwr/s） ，单位是 KB
块 I/O 延迟（iodelay），包括等待同步块 I/O 和换入块 I/O 结束的时间，单位是时钟周期。
$ pidstat -d 1 13:39:51 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 13:39:52 102 916 0.00 4.00 0.00 0 rsyslogd
pidstat查看每个进程的I/O情况
$ iotopTotal DISK READ : 0.00 B/s | Total DISK WRITE : 7.85 K/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 15055 be/3 root 0.00 B/s 7.85 K/s 0.00 % 0.00 % systemd-journald
iotop。它是一个类似于 top 的工具，你可以按照 I/O 大小对进程排序，然后找到 I/O 较大的那些进程。
观测工具
第24、25讲 磁盘io怎么工作的
CPU0 的使用率非常高，它的系统 CPU 使用率（sys%）为 6%，而 iowait 超过了 90%。这说明 CPU0 上，可能正在运行 I/O 密集型的进程。
python 进程的 CPU 使用率已经达到了 6%，而其余进程的 CPU 使用率都比较低，不超过 0.3%。看起来 python 是个可疑进程。记下 python 进程的 PID 号 18940
再看内存的使用情况，总内存 8G，剩余内存只有 730 MB，而 Buffer/Cache 占用内存高达 6GB 之多，这说明内存主要被缓存占用。虽然大部分缓存可回收，我们还是得了解下缓存的去处，确认缓存使用都是合理的。
用 top ，来观察 CPU 和内存的使用情况
# -d表示显示I/O性能指标，-x表示显示扩展统计（即所有I/O指标） $ iostat -x -d 1 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 64.00 0.00 32768.00 0.00 0.00 0.00 0.00 0.00 7270.44 1102.18 0.00 512.00 15.50 99.20
观察 iostat 的最后一列，你会看到，磁盘 sda 的 I/O 使用率已经高达 99%，很可能已经接近 I/O 饱和。
再看前面的各个指标，每秒写磁盘请求数是 64 ，写大小是 32 MB，写请求的响应时间为 7 秒，而请求队列长度则达到了 1100。超慢的响应时间和特长的请求队列长度，进一步验证了 I/O 已经饱和的猜想。此时，sda 磁盘已经遇到了严重的性能瓶颈
运行 iostat 命令，观察 I/O 的使用情况
观察现象
$ pidstat -d 1 15:08:35 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 15:08:36 0 18940 0.00 45816.00 0.00 96 python 15:08:36 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 15:08:37 0 354 0.00 0.00 0.00 350 jbd2/sda1-8 15:08:37 0 18940 0.00 46000.00 0.00 96 python 15:08:37 0 20065 0.00 0.00 0.00 1503 kworker/u4:2
只有 python 进程的写比较大，而且每秒写的数据超过 45 MB，比上面 iostat 发现的 32MB 的结果还要大。很明显，正是 python 进程导致了 I/O 瓶颈。
再往下看 iodelay 项。虽然只有 python 在大量写数据，但你应该注意到了，有两个进程 （kworker 和 jbd2 ）的延迟，居然比 python 进程还大很多。这其中，kworker 是一个内核线程，而 jbd2 是 ext4 文件系统中，用来保证数据完整性的内核线程。他们都是保证文件系统基本功能的内核线程，所以具体细节暂时就不用管了，我们只需要明白，它们延迟的根源还是大量 I/O
综合 pidstat 的输出来看，还是 python 进程的嫌疑最大
使用 pidstat 加上 -d 参数，观察每个进程的 I/O 情况
进程向文件描述符编号为 3 的文件中，写入了 300MB 的数据。看来，它应该是我们要找的文件。不过，write() 调用中只能看到文件的描述符编号，文件名和路径还是未知的。
后面的 stat() 调用，你可以看到，它正在获取 /tmp/logtest.txt.1 的状态。 这种“点 + 数字格式”的文件，在日志回滚中非常常见。我们可以猜测，这是第一个日志回滚文件，而正在写的日志文件路径，则是 /tmp/logtest.txt。
读写文件必须通过系统调用完成，观察系统调用情况，就可以知道进程正在写的文件。运行 strace 命令，并通过 -p 18940 指定 python 进程的 PID 号
FD 表示文件描述符号，TYPE 表示文件类型，NAME 表示文件路径
看最后一行，这说明，这个进程打开了文件 /tmp/logtest.txt，并且它的文件描述符是 3 号，而 3 后面的 w ，表示以写的方式打开。
这跟刚才 strace 完我们猜测的结果一致，看来这就是问题的根源：进程 18940 以每次 300MB 的速度，在“疯狂”写日志，而日志文件的路径是 /tmp/logtest.txt
使用lsof用来查看进程打开文件列表，不过，这里的“文件”不只有普通文件，还包括了目录、块设备、动态库、网络套接字等。
定位业务代码进行优化
分析根源
第26讲案例排查哪里疯狂写日志
1.使用df命令确认磁盘空间充足
两个 CPU 的 iowait 都非常高。特别是 CPU0， iowait 已经高达 94 %，而剩余内存还有 3GB，看起来也是充足的
再往下看，进程部分有一个 python 进程的 CPU 使用率稍微有点高，达到了 14%。虽然 14% 并不能成为性能瓶颈，不过有点嫌疑——可能跟 iowait 的升高有关
是
确认PID 号为 12280 的 python 进程是不是案例进程
2.使用top命令观察情况
-d 选项是指显示出 I/O 的性能指标
x 选项是指显示出扩展统计信息（即显示所有 I/O 指标）
$ iostat -d -x 1Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda 0.00 71.00 0.00 32912.00 0.00 0.00 0.00 0.00 0.00 18118.31 241.89 0.00 463.55 13.86 98.40
磁盘 sda 的 I/O 使用率已经达到 98% ，接近饱和了。而且，写请求的响应时间高达 18 秒，每秒的写数据为 32 MB，显然写磁盘碰到了瓶颈。
1.观察磁盘整体性能情况
$ pidstat -d 1 14:39:14 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command 14:39:15 0 12280 0.00 335716.00 0.00 0 python
该进程每秒写300多M数据。这说明，正是案例应用引发 I/O 的性能瓶颈。
2.观察进程I/O情况
strace -p 12280 2>&1 | grep write
（写文件是由子线程执行的，所以查不到。在strace -p PID后加上-f，多进程和多线程都可以跟踪）
没有输出，即没有找到。可能工具有问题，换一个
3.使用strace定位在写哪个文件
# 切换到工具目录 $ cd /usr/share/bcc/tools # -C 选项表示输出新内容时不清空屏幕 $ ./filetop -C TID COMM READS WRITES R_Kb W_Kb T FILE 514 python 0 1 0 2832 R 669.txt 514 python 0 1 0 2490 R 667.txt 514 python 0 1 0 2685 R 671.txt 514 python 0 1 0 2392 R 670.txt 514 python 0 1 0 2050 R 672.txt...TID COMM READS WRITES R_Kb W_Kb T FILE 514 python 2 0 5957 0 R 651.txt 514 python 2 0 5371 0 R 112.txt 514 python 2 0 4785 0 R 861.txt 514 python 2 0 4736 0 R 213.txt 514 python 2 0 4443 0 R 45.txt
多观察一会儿，你就会发现，每隔一段时间，线程号为 514 的 python 应用就会先写入大量的 txt 文件，再大量地读
$ ps -efT | grep 514root 12280 514 14626 33 14:47 pts/0 00:00:05 /usr/local/bin/python /app.py
线程号为 514 的线程，属于哪个进程呢？
只给出了文件名称，没文件路径，要继续找
4.使用filetop工具排查
$ opensnoop 12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/650.txt 12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/651.txt 12280 python 6 0 /tmp/9046db9e-fe25-11e8-b13f-0242ac110002/652.txt
这些 txt 路径位于 /tmp 目录下。你还能看到，它打开的文件数量，按照数字编号，从 0.txt 依次增大到 999.txt，这可远多于前面用 filetop 看到的数量。
$ ls /tmp/9046db9e-fe25-11e8-b13f-0242ac110002 | wc -l ls: cannot access '/tmp/9046db9e-fe25-11e8-b13f-0242ac110002': No such file or directory 0
$ opensnoop 12280 python 6 0 /tmp/defee970-fe25-11e8-b13f-0242ac110002/261.txt 12280 python 6 0 /tmp/defee970-fe25-11e8-b13f-0242ac110002/840.txt 12280 python 6 0 /tmp/defee970-fe25-11e8-b13f-0242ac110002/136.txt
这时的路径已经变成了另一个目录。这说明，这些目录都是应用程序动态生成的，用完就删了。
操作后却发现，目录居然不存在了。回到 opensnoop 再观察一会儿
我们可以大胆猜测，案例应用在写入 1000 个 txt 文件后，又把这些内容读到内存中进行处理。我们来检查一下，这个目录中是不是真的有 1000 个我文件
结合前面的所有分析，我们基本可以判断，案例应用会动态生成一批文件，用来临时存储数据，用完就会删除它们。但不幸的是，正是这些文件读写，引发了 I/O 的性能瓶颈，导致整个处理过程非常慢。
5.使用opensnoop工具获取打开的文件路径
第27讲，排查磁盘I/O延迟高案例
mysql，提供数据存储查询服务
商品搜索应用，用于提供http接口查询mysql
数据处理应用，干扰项，不断清除文件系统缓存
1.启动3个服务
$ curl http://192.168.0.10:10000/products/geektimeGot data: () in 15.364538192749023 sec
请求http接口，发现接口执行了15秒
$ while true; do curl http://192.168.0.10:10000/products/geektime; sleep 5; done
（真正遇到问题，可直接看是否慢sql）在具体分析前，为了避免在分析过程中客户端的请求结束，我们把 curl 命令放到一个循环里执行。同时，为了避免给系统过大压力，我们设置在每次查询后，都先等待 5 秒，然后再开始新的请求。
背景：
两个 CPU 的 iowait 都比较高，特别是 CPU0，iowait 已经超过 60%。而具体到各个进程， CPU 使用率并不高，最高的也只有 1.7%
1.使用top分析CPU使用情况
$ iostat -d -x 1Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util...sda 273.00 0.00 32568.00 0.00 0.00 0.00 0.00 0.00 7.90 0.00 1.16 119.30 0.00 3.56 97.20
磁盘 sda 每秒的读数据为 32 MB， 而 I/O 使用率高达 97% ，接近饱和，这说明，磁盘 sda 的读取确实碰到了性能瓶颈。
2.iostat 命令，看看有没有 I/O 性能问题
# -d选项表示展示进程的I/O情况$ pidstat -d 112:04:11 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command12:04:12 999 27458 32640.00 0.00 0.00 0 mysqld12:04:12 0 27617 4.00 4.00 0.00 3 python12:04:12 0 27864 0.00 4.00 0.00 0 systemd-journal
PID 为 27458 的 mysqld 进程正在进行大量的读，而且读取速度是 32 MB/s，跟刚才 iostat 的发现一致。两个结果一对比，我们自然就找到了磁盘 I/O 瓶颈的根源，即 mysqld 进程。
这有可能是个慢查询问题。可是，回想一下，慢查询的现象大多是 CPU 使用率高（比如 100% ），但这里看到的却是 I/O 问题。看来，这并不是一个单纯的慢查询问题，我们有必要分析一下 MySQL 读取的数据。
3.pidstat 命令，观察进程的 I/O 情况
线程 28014 正在读取大量数据，且读取文件的描述符编号为 38.这儿的 38 又对应着哪个文件呢？
$ lsof -p 28014
lsof 并没有给出任何输出。实际上，如果你查看 lsof 命令的返回值(echo $?)，就会发现，这个命令的执行失败了。
-p 参数需要指定进程号，而我们刚才传入的是线程号，所以 lsof 失败了。
lsof 命令，并且指定线程号 28014 ，具体查看这个可疑线程和可疑文件
MYD 文件，是 MyISAM 引擎用来存储表数据的文件
文件名就是数据表的名字；
而这个文件的父目录，也就是数据库的名字
根据文件描述符（FD）的编号，我们知道，描述符为 38 的是一个路径为 /var/lib/mysql/test/products.MYD 的文件。这里注意， 38 后面的 u 表示， mysqld 以读写的方式访问文件。
把线程号换成进程号，继续执行 lsof 命令：
4.执行 strace 命令，并且指定 mysqld 的进程号 27458
mysql> show full processlist;+----+------+-----------------+------+---------+------+--------------+-----------------------------------------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+-----------------+------+---------+------+--------------+-----------------------------------------------------+| 27 | root | localhost | test | Query | 0 | init | show full processlist || 28 | root | 127.0.0.1:42262 | test | Query | 1 | Sending data | select * from products where productName='geektime' |+----+------+-----------------+------+---------+------+--------------+-----------------------------------------------------+2 rows in set (0.00 sec)
可看到 select * from products where productName=‘geektime’ 这条 SQL 语句的执行时间比较长
5.在mysql里执行 show full processlist 命令
6.解析sql确认是缺少索引（这里不展开）
停止dataservice项目后，接口查询变快了，从15s=>0.1s，虽然比加索引慢
$ vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 1 0 6809304 1368 856744 0 0 32640 0 52 478 1 0 50 49 0 0 1 0 6776620 1368 889456 0 0 32640 0 33 490 0 0 50 49 0 0 0 0 6747540 1368 918576 0 0 29056 0 42 568 0 0 56 44 0 0 0 0 6747540 1368 918576 0 0 0 0 40 141 1 0 100 0 0 0 0 0 6747160 1368 918576 0 0 0 0 40 148 0 1 99 0 0
源码：https://github.com/feiskyer/linux-perf-examples/blob/master/mysql-slow/dataservice.py
DataService会把 /proc/sys/vm/drop_caches 改成 1。
echo 1>/proc/sys/vm/drop_caches表示释放pagecache，也就是文件缓存，而mysql读书的数据就是文件缓存，dataservice不停的释放文件缓存，就导致MySQL都无法利用磁盘缓存，也就慢了
磁盘读（bi）和 iowait（wa）刚开始还是挺大的，但没过多久，就都变成了 0 。换句话说，I/O 瓶颈消失了
运行下面的 vmstat 命令，观察 I/O 的变化情况
7.题目思考：确认dataService项目对慢查的影响
第28案例，排查慢sql
1.部署了redis服务和一个python应用，python应用提供了一个查询接口用于从redis查询数据
2.在往redis插入5k条数据后，使用接口查询redis数据耗了10多分钟
背景
CPU0 的 iowait 比较高，已经达到了 84%；而各个进程的 CPU 使用率都不太高，最高的 python 和 redis-server ，也分别只有 8% 和 5%。再看内存，总内存 8GB，剩余内存还有 7GB 多，显然内存也没啥问题。
1.执行top分析系统CPU使用情况
$ iostat -d -x 1Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util...sda 0.00 492.00 0.00 2672.00 0.00 176.00 0.00 26.35 0.00 1.76 0.00 0.00 5.43 0.00 0.00
磁盘 sda 每秒的写数据（wkB/s）为 2.5MB，I/O 使用率（%util）是 0。看来，虽然有些 I/O 操作，但并没导致磁盘的 I/O 瓶颈。
回想一下，今天的案例问题是从 Redis 缓存中查询数据慢。对查询来说，对应的 I/O 应该是磁盘的读操作，但刚才我们用 iostat 看到的却是写操作。虽说 I/O 本身并没有性能瓶颈，但这里的磁盘写也是比较奇怪的。为什么会有磁盘写呢？那我们就得知道，到底是哪个进程在写磁盘。
2.iostat 命令，查看有没有 I/O 性能问题
$ pidstat -d 112:49:35 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command12:49:36 0 368 0.00 16.00 0.00 86 jbd2/sda1-812:49:36 100 9085 0.00 636.00 0.00 1 redis-server
从 pidstat 的输出，我们看到，I/O 最多的进程是 PID 为 9085 的 redis-server，并且它也刚好是在写磁盘。这说明，确实是 redis-server 在进行磁盘写。
3。在终端一中运行下面的 pidstat 命令，查询i/o都来自哪些进程：
事实上，从系统调用来看， epoll_pwait、read、write、fdatasync 这些系统调用都比较频繁。那么，刚才观察到的写磁盘，应该就是 write 或者 fdatasync 导致的了。
4.执行 strace 命令，并且指定 redis-server 的进程号 9085，看看到底再写什么
描述符编号为 3 的是一个 pipe 管道，5 号是 eventpoll，7 号是一个普通文件，而 8 号是一个 TCP socket。
结合磁盘写的现象，我们知道，只有 7 号普通文件才会产生磁盘写，而它操作的文件路径是 /data/appendonly.aof，相应的系统调用包括 write 和 fdatasync。
看到这个文件路径以及 fdatasync 的系统调用，你应该能想到，这对应着正是 Redis 持久化配置中的 appendonly 和 appendfsync 选项。很可能是因为它们的配置不合理，导致磁盘写比较多。
5.运行 lsof 命令，找出这些系统调用的操作对象
追加文件日志参数appendfsync：always，代表每个操作都会执行一次 fsync，是最为安全的方式
$ docker exec -it redis redis-cli config get 'append*'1) \"appendfsync\"2) \"always\"3) \"appendonly\"4) \"yes\"
appendfsync 配置的是 always，意味着每次写数据时，都会调用一次 fsync，从而造成比较大的磁盘 I/O 压力。
6.查看当前redis配置
$ strace -f -p 9085 -T -tt -e fdatasyncstrace: Process 9085 attached with 4 threads[pid 9085] 14:22:52.013547 fdatasync(7) = 0 <0.007112>[pid 9085] 14:22:52.022467 fdatasync(7) = 0 <0.008572>[pid 9085] 14:22:52.032223 fdatasync(7) = 0 <0.006769>...[pid 9085] 14:22:52.139629 fdatasync(7) = 0 <0.008183>
每隔 10ms 左右，就会有一次 fdatasync 调用，并且每次调用本身也要消耗 7~8ms。不管哪种方式，都可以验证我们的猜想，配置确实不合理。这样，我们就找出了 Redis 正在进行写入的文件，也知道了产生大量 I/O 的原因。
7.观察fdatasync这个系统调用的情况
上面有sadd写操作
在下最终结论前，我们还是要确认一下，8 号 TCP socket 对应的 Redis 客户端，到底是不是我们的案例应用。
8.查询为什么会有磁盘写
# 由于这两个容器共享同一个网络命名空间，所以我们只需要进入app的网络命名空间即可$ PID=$(docker inspect --format {{.State.Pid}} app)# -i表示显示网络套接字信息$ nsenter --target $PID --net -- lsof -iCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEredis-ser 9085 systemd-network 6u IPv4 15447972 0t0 TCP localhost:6379 (LISTEN)redis-ser 9085 systemd-network 8u IPv4 15448709 0t0 TCP localhost:6379->localhost:32996 (ESTABLISHED)python 9181 root 3u IPv4 15448677 0t0 TCP *:http (LISTEN)python 9181 root 5u IPv4 15449632 0t0 TCP localhost:32996->localhost:6379 (ESTABLISHED)
localhost:32996 对应的，正是我们的 Python 应用程序（进程号为 9181）。
9.查询8号tcp socket对应的tcp链接信息
把 appendfsync 改成 everysec
1.调整reids 把 appendfsync 改成 everysec
1.调整应用源码逻辑
10.进行优化
分析根源：
第29案例，排查redis响应慢
IO性能指标
子主题
第一个维度，从文件系统和磁盘 I/O 的性能指标出发。换句话说，当你想查看某个性能指标时，要清楚知道，哪些工具可以做到。
1.先用 iostat 发现磁盘 I/O 性能瓶颈
2.再借助 pidstat ，定位出导致瓶颈的进程；
3.随后分析进程的 I/O 行为；
4.最后，结合应用程序的原理，分析这些 I/O 的来源
为了缩小排查范围，我通常会先运行那几个支持指标较多的工具，如 iostat、vmstat、pidstat 等。然后再根据观察到的现象，结合系统和应用程序的原理，寻找下一步的分析方向。
如何又快又准地找出系统的 I/O 瓶颈
第30篇套路总结
使用fio对系统进行测试（这里不做笔记，有需要看原文）
I/O 基准测试
栈图
第一，可以用追加写代替随机写，减少寻址开销，加快 I/O 写的速度
第二，可以借助缓存 I/O ，充分利用系统缓存，降低实际 I/O 的次数。
三，可以在应用程序内部构建自己的缓存，或者用 Redis 这类外部缓存系统。这样，一方面，能在应用程序内部，控制缓存的数据和生命周期；另一方面，也能降低其他应用程序使用缓存对自身的影响。
第四，在需要频繁读写同一块磁盘空间时，可以用 mmap 代替 read/write，减少内存的拷贝次数。
第五，在需要同步写的场景中，尽量将写请求合并，而不是让每个请求都同步写入磁盘，即可以用 fsync() 取代 O_SYNC。
第六，在多个应用程序共享相同磁盘时，为了保证 I/O 不被某个应用完全占用，推荐你使用 cgroups 的 I/O 子系统，来限制进程 / 进程组的 IOPS 以及吞吐量。
最后，在使用 CFQ 调度器时，可以用 ionice 来调整进程的 I/O 调度优先级，特别是提高核心应用的 I/O 优先级。ionice 支持三个优先级类：Idle、Best-effort 和 Realtime。其中， Best-effort 和 Realtime 还分别支持 0-7 的级别，数值越小，则表示优先级别越高
应用程序优化
相比于 ext4 ，xfs 支持更大的磁盘分区和更大的文件数量，如 xfs 支持大于 16TB 的磁盘。但是 xfs 文件系统的缺点在于无法收缩，而 ext4 则可以。
第一，你可以根据实际负载场景的不同，选择最适合的文件系统。比如 Ubuntu 默认使用 ext4 文件系统，而 CentOS 7 默认使用 xfs 文件系统
比如， 使用 tune2fs 这个工具，可以调整文件系统的特性（tune2fs 也常用来查看文件系统超级块的内容）。 而通过 /etc/fstab ，或者 mount 命令行参数，我们可以调整文件系统的日志模式和挂载选项等。
第二，在选好文件系统后，还可以进一步优化文件系统的配置选项，包括文件系统的特性（如 ext_attr、dir_index）、日志模式（如 journal、ordered、writeback）、挂载选项（如 noatime）等等
比如，你可以优化 pdflush 脏页的刷新频率（比如设置 dirty_expire_centisecs 和 dirty_writeback_centisecs）以及脏页的限额（比如调整 dirty_background_ratio 和 dirty_ratio 等）。
第三，可以优化文件系统的缓存。
比如 /dev/shm/ ，就是大多数 Linux 默认配置的一个内存文件系统，它的大小默认为总内存的一半。
最后，在不需要持久化时，你还可以用内存文件系统 tmpfs，以获得更好的 I/O 性能 。tmpfs 把数据直接保存在内存中，而不是磁盘中
文件系统优化
第一，最简单有效的优化方法，就是换用性能更好的磁盘，比如用 SSD 替代 HDD
第二，我们可以使用 RAID ，把多块磁盘组合成一个逻辑磁盘，构成冗余独立磁盘阵列。这样做既可以提高数据的可靠性，又可以提升数据的访问性能。
第三，针对磁盘和应用程序 I/O 模式的特征，我们可以选择最适合的 I/O 调度算法。比方说，SSD 和虚拟机中的磁盘，通常用的是 noop 调度算法。而数据库应用，我更推荐使用 deadline 算法。
第四，我们可以对应用程序的数据，进行磁盘级别的隔离。比如，我们可以为日志、数据库等 I/O 压力比较重的应用，配置单独的磁盘
调整内核选项 /sys/block/sdb/queue/read_ahead_kb，默认大小是 128 KB，单位为 KB
使用 blockdev 工具设置，比如 blockdev --setra 8192 /dev/sdb，注意这里的单位是 512B（0.5KB），所以它的数值总是 read_ahead_kb 的两倍。
比如，你可以通过下面两种方法，调整 /dev/sdb 的预读大小。
第五，在顺序读比较多的场景中，我们可以增大磁盘的预读数据
第六，我们可以优化内核块设备 I/O 的选项。比如，可以调整磁盘队列的长度 /sys/block/sdb/queue/nr_requests，适当增大队列长度，可以提升磁盘的吞吐量（当然也会导致 I/O 延迟增大）
比如，你可以查看 dmesg 中是否有硬件 I/O 故障的日志。 还可以使用 badblocks、smartctl 等工具，检测磁盘的硬件问题，或用 e2fsck 等来检测文件系统的错误。如果发现问题，你可以使用 fsck 等工具来修复
最后，要注意，磁盘本身出现硬件错误，也会导致 I/O 性能急剧下降，所以发现磁盘性能急剧下降时，你还需要确认，磁盘本身是不是出现了硬件错误。
磁盘优化
IO性能优化
第31篇性能优化思路
所谓阻塞 I/O，是指应用程序在执行 I/O 操作后，如果没有获得响应，就会阻塞当前线程，不能执行其他任务。
所谓非阻塞 I/O，是指应用程序在执行 I/O 操作后，不会阻塞当前的线程，可以继续执行其他的任务
首先我们来看阻塞和非阻塞 I/O。根据应用程序是否阻塞自身运行，可以把 I/O 分为阻塞 I/O 和非阻塞 I/O。
所谓同步 I/O，是指收到 I/O 请求后，系统不会立刻响应应用程序；等到处理完成，系统才会通过系统调用的方式，告诉应用程序 I/O 结果。
所谓异步 I/O，是指收到 I/O 请求后，系统会先告诉应用程序 I/O 请求已经收到，随后再去异步处理；等处理完成后，系统再通过事件通知的方式，告诉应用程序结果
再来看同步 I/O 和异步 I/O。根据 I/O 响应的通知方式的不同，可以把文件 I/O 分为同步 I/O 和异步 I/O
你可以看出，阻塞 / 非阻塞和同步 / 异步，其实就是两个不同角度的 I/O 划分方式。它们描述的对象也不同，阻塞 / 非阻塞针对的是 I/O 调用者（即应用程序），而同步 / 异步针对的是 I/O 执行者（即系统）。
阻塞、非阻塞 I/O 与同步、异步 I/O 的区别和联系
第32答疑篇
IO篇
中心主题
职业：本科
0 条评论
回复 删除
下一页
