Linux性能优化

作者 | mikelLam
来源 | https://www.ctq6.cn/
原文 | https://www.ctq6.cn/linux 性能优化 /

性能优化

性能指标

高并发和响应快对应着性能优化的两个核心指标：吞吐和延时

应用负载角度：直接影响了产品终端的用户体验
系统资源角度：资源使用率、饱和度等

性能问题的本质就是系统资源已经到达瓶颈，但请求的处理还不够快，无法支撑更多的请求。性能分析实际上就是找出应用或系统的瓶颈，设法去避免或缓解它们。

选择指标评估应用程序和系统性能
为应用程序和系统设置性能目标
进行性能基准测试
性能分析定位瓶颈
性能监控和告警

对于不同的性能问题要选取不同的性能分析工具。下面是常用的 Linux Performance Tools 以及对应分析的性能问题类型。

到底应该怎么理解“平均负载”

** 平均负载：** 单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。它和我们传统意义上理解的 CPU 使用率并没有直接关系。
其中不可中断进程是正处于内核态关键流程中的进程（如常见的等待设备的 I/O 响应）。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

平均负载多少时合理

实际生产环境中将系统的平均负载监控起来，根据历史数据判断负载的变化趋势。当负载存在明显升高趋势时，及时进行分析和调查。当然也可以当设置阈值（如当平均负载高于 CPU 数量的 70% 时）
现实工作中我们会经常混淆平均负载和 CPU 使用率的概念，其实两者并不完全对等：

CPU 密集型进程，大量 CPU 使用会导致平均负载升高，此时两者一致
I/O 密集型进程，等待 I/O 也会导致平均负载升高，此时 CPU 使用率并不一定高
大量等待 CPU 的进程调度会导致平均负载升高，此时 CPU 使用率也会比较高

平均负载高时可能是 CPU 密集型进程导致，也可能是 I/O 繁忙导致。具体分析时可以结合 mpstat/pidstat 工具辅助分析负载来源

CPU

CPU 上下文切换 (上)

CPU 上下文切换，就是把前一个任务的 CPU 上下文（CPU 寄存器和 PC）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的位置，运行新任务。其中，保存下来的上下文会存储在系统内核中，待任务重新调度执行时再加载，保证原来的任务状态不受影响。
按照任务类型，CPU 上下文切换分为：

进程上下文切换
线程上下文切换
中断上下文切换

进程上下文切换

Linux 进程按照等级权限将进程的运行空间分为内核空间和用户空间。从用户态向内核态转变时需要通过系统调用来完成。
一次系统调用过程其实进行了两次 CPU 上下文切换：

CPU 寄存器中用户态的指令位置先保存起来，CPU 寄存器更新为内核态指令的位置，跳转到内核态运行内核任务；
系统调用结束后，CPU 寄存器恢复原来保存的用户态数据，再切换到用户空间继续运行。

系统调用过程中并不会涉及虚拟内存等进程用户态资源，也不会切换进程。和传统意义上的进程上下文切换不同。因此系统调用通常称为特权模式切换。
进程是由内核管理和调度的，进程上下文切换只能发生在内核态。因此相比系统调用来说，在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存，栈保存下来。再加载新进程的内核态后，还要刷新进程的虚拟内存和用户栈。
进程只有在调度到 CPU 上运行时才需要切换上下文，有以下几种场景： CPU 时间片轮流分配，系统资源不足导致进程挂起，进程通过 sleep 函数主动挂起，高优先级进程抢占时间片，硬件中断时 CPU 上的进程被挂起转而执行内核中的中断服务。

线程上下文切换

线程上下文切换分为两种：

前后线程同属于一个进程，切换时虚拟内存资源不变，只需要切换线程的私有数据，寄存器等；
前后线程属于不同进程，与进程上下文切换相同。

同进程的线程切换消耗资源较少，这也是多线程的优势。

中断上下文切换

中断上下文切换并不涉及到进程的用户态，因此中断上下文只包括内核态中断服务程序执行所必须的状态（CPU 寄存器，内核堆栈，硬件中断参数等）。
中断处理优先级比进程高，所以中断上下文切换和进程上下文切换不会同时发生

CPU 上下文切换 (下)

通过 vmstat 可以查看系统总体的上下文切换情况

vmstat 5         #每隔5s输出一组数据
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 103388 145412 511056    0    0    18    60    1    1  2  1 96  0  0
 0  0      0 103388 145412 511076    0    0     0     2  450 1176  1  1 99  0  0
 0  0      0 103388 145412 511076    0    0     0     8  429 1135  1  1 98  0  0
 0  0      0 103388 145412 511076    0    0     0     0  431 1132  1  1 98  0  0
 0  0      0 103388 145412 511076    0    0     0    10  467 1195  1  1 98  0  0
 1  0      0 103388 145412 511076    0    0     0     2  426 1139  1  0 99  0  0
 4  0      0  95184 145412 511108    0    0     0    74  500 1228  4  1 94  0  0
 0  0      0 103512 145416 511076    0    0     0   455  723 1573 12  3 83  2  0

cs （context switch）每秒上下文切换次数
in （interrupt）每秒中断次数
r （runnning or runnable）就绪队列的长度，正在运行和等待 CPU 的进程数
b （Blocked）处于不可中断睡眠状态的进程数

要查看每个进程的详细情况，需要使用 pidstat 来查看每个进程上下文切换情况

pidstat -w 5
14时51分16秒   UID       PID   cswch/s nvcswch/s  Command
14时51分21秒     0         1      0.80      0.00  systemd
14时51分21秒     0         6      1.40      0.00  ksoftirqd/0
14时51分21秒     0         9     32.67      0.00  rcu_sched
14时51分21秒     0        11      0.40      0.00  watchdog/0
14时51分21秒     0        32      0.20      0.00  khugepaged
14时51分21秒     0       271      0.20      0.00  jbd2/vda1-8
14时51分21秒     0      1332      0.20      0.00  argusagent
14时51分21秒     0      5265     10.02      0.00  AliSecGuard
14时51分21秒     0      7439      7.82      0.00  kworker/0:2
14时51分21秒     0      7906      0.20      0.00  pidstat
14时51分21秒     0      8346      0.20      0.00  sshd
14时51分21秒     0     20654      9.82      0.00  AliYunDun
14时51分21秒     0     25766      0.20      0.00  kworker/u2:1
14时51分21秒     0     28603      1.00      0.00  python3

cswch 每秒自愿上下文切换次数（进程无法获取所需资源导致的上下文切换）
nvcswch 每秒非自愿上下文切换次数（时间片轮流等系统强制调度）

vmstat 1 1    #首先获取空闲系统的上下文切换次数
sysbench --threads=10 --max-time=300 threads run #模拟多线程切换问题

vmstat 1 1    #新终端观察上下文切换情况
此时发现cs数据明显升高，同时观察其他指标：
r列： 远超系统CPU个数，说明存在大量CPU竞争
us和sy列： sy列占比80%，说明CPU主要被内核占用
in列： 中断次数明显上升，说明中断处理也是潜在问题

说明运行 / 等待 CPU 的进程过多，导致大量的上下文切换，上下文切换导致系统的 CPU 占用率高

pidstat -w -u 1  #查看到底哪个进程导致的问题

从结果中看出是 sysbench 导致 CPU 使用率过高，但是 pidstat 输出的上下文次数加起来也并不多。分析 sysbench 模拟的是线程的切换，因此需要在 pidstat 后加 -t 参数查看线程指标。
另外对于中断次数过多，我们可以通过 /proc/interrupts 文件读取

watch -d cat /proc/interrupts

发现次数变化速度最快的是重调度中断（RES），该中断用来唤醒空闲状态的 CPU 来调度新的任务运行。分析还是因为过多任务的调度问题，和上下文切换分析一致。

某个应用的 CPU 使用率达到 100%，怎么办？

Linux 作为多任务操作系统，将 CPU 时间划分为很短的时间片，通过调度器轮流分配给各个任务使用。为了维护 CPU 时间，Linux 通过事先定义的节拍率，触发时间中断，并使用全局变了 jiffies 记录开机以来的节拍数。时间中断发生一次该值 +1.
CPU 使用率，除了空闲时间以外的其他时间占总 CPU 时间的百分比。可以通过 /proc/stat 中的数据来计算出 CPU 使用率。因为 /proc/stat 时开机以来的节拍数累加值，计算出来的是开机以来的平均 CPU 使用率，一般意义不大。可以间隔取一段时间的两次值作差来计算该段时间内的平均 CPU 使用率。 性能分析工具给出的都是间隔一段时间的平均 CPU 使用率，要注意间隔时间的设置。
CPU 使用率可以通过 top 或 ps 来查看。分析进程的 CPU 问题可以通过 perf，它以性能事件采样为基础，不仅可以分析系统的各种事件和内核性能，还可以用来分析指定应用程序的性能问题。
perf top / perf record / perf report （-g 开启调用关系的采样）

sudo docker run --name nginx -p 10000:80 -itd feisky/nginx
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm

ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能

发现此时每秒可承受请求给长少，此时将测试的请求数从 100 增加到 10000。在另外一个终端运行 top 查看每个 CPU 的使用率。发现系统中几个 php-fpm 进程导致 CPU 使用率骤升。
接着用 perf 来分析具体是 php-fpm 中哪个函数导致该问题。

perf top -g -p XXXX #对某一个php-fpm进程进行分析

发现其中 sqrt 和 add_function 占用 CPU 过多，此时查看源码找到原来是 sqrt 中在发布前没有删除测试代码段，存在一个百万次的循环导致。将该无用代码删除后发现 nginx 负载能力明显提升

系统的 CPU 使用率很高，为什么找不到高 CPU 的应用？

sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:sp
sudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp
ab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试

实验结果中每秒请求数依旧不高，我们将并发请求数降为 5 后，nginx 负载能力依旧很低。
此时用 top 和 pidstat 发现系统 CPU 使用率过高，但是并没有发现 CPU 使用率高的进程。
出现这种情况一般时我们分析时遗漏的什么信息，重新运行 top 命令并观察一会。发现就绪队列中处于 Running 状态的进行过多，超过了我们的并发请求次数 5. 再仔细查看进程运行数据，发现 nginx 和 php-fpm 都处于 sleep 状态，真正处于运行的却是几个 stress 进程。
下一步就利用 pidstat 分析这几个 stress 进程，发现没有任何输出。用 ps aux 交叉验证发现依旧不存在该进程。说明不是工具的问题。再 top 查看发现 stress 进程的进程号变化了，此时有可能时以下两种原因导致：

进程不停的崩溃重启（如段错误 / 配置错误等），此时进程退出后可能又被监控系统重启；
短时进程导致，即其他应用内部通过 exec 调用的外面命令，这些命令一般只运行很短时间就结束，很难用 top 这种间隔较长的工具来发现

可以通过 pstree 来查找 stress 的父进程，找出调用关系。

pstree | grep stress

发现是 php-fpm 调用的该子进程，此时去查看源码可以看出每个请求都会调用一个 stress 命令来模拟 I/O 压力。之前 top 显示的结果是 CPU 使用率升高，是否真的是由该 stress 命令导致的，还需要继续分析。代码中给每个请求加了 verbose=1 的参数后可以查看 stress 命令的输出，在中断测试该命令结果显示 stress 命令运行时存在因权限问题导致的文件创建失败的 bug。
此时依旧只是猜测，下一步继续通过 perf 工具来分析。性能报告显示确实时 stress 占用了大量的 CPU，通过修复权限问题来优化解决即可.

系统中出现大量不可中断进程和僵尸进程怎么办？

进程状态

R Running/Runnable，表示进程在 CPU 的就绪队列中，正在运行或者等待运行；
D Disk Sleep，不可中断状态睡眠，一般表示进程正在跟硬件交互，并且交互过程中不允许被其他进程中断；
Z Zombie，僵尸进程，表示进程实际上已经结束，但是父进程还没有回收它的资源；
S Interruptible Sleep，可中断睡眠状态，表示进程因为等待某个事件而被系统挂起，当等待事件发生则会被唤醒并进入 R 状态；
I Idle，空闲状态，用在不可中断睡眠的内核线程上。该状态不会导致平均负载升高；
T Stop/Traced，表示进程处于暂停或跟踪状态（SIGSTOP/SIGCONT， GDB 调试）；
X Dead，进程已经消亡，不会在 top/ps 中看到。

对于不可中断状态，一般都是在很短时间内结束，可忽略。但是如果系统或硬件发生故障，进程可能会保持不可中断状态很久，甚至系统中出现大量不可中断状态，此时需注意是否出现了 I/O 性能问题。
僵尸进程一般多进程应用容易遇到，父进程来不及处理子进程状态时子进程就提前退出，此时子进程就变成了僵尸进程。大量的僵尸进程会用尽 PID 进程号，导致新进程无法建立。

磁盘 O_DIRECT 问题

sudo docker run --privileged --name=app -itd feisky/app:iowait
ps aux | grep '/app'

可以看到此时有多个 app 进程运行，状态分别时 Ss+ 和 D+。其中后面 s 表示进程是一个会话的领导进程，+ 号表示前台进程组。
其中进程组表示一组相互关联的进程，子进程是父进程所在组的组员。会话指共享同一个控制终端的一个或多个进程组。
用 top 查看系统资源发现：1）平均负载在逐渐增加，且 1 分钟内平均负载达到了 CPU 个数，说明系统可能已经有了性能瓶颈；2）僵尸进程比较多且在不停增加；3）us 和 sys CPU 使用率都不高，iowait 却比较高；4）每个进程 CPU 使用率也不高，但有两个进程处于 D 状态，可能在等待 IO。
分析目前数据可知：iowait 过高导致系统平均负载升高，僵尸进程不断增长说明有程序没能正确清理子进程资源。
用 dstat 来分析，因为它可以同时查看 CPU 和 I/O 两种资源的使用情况，便于对比分析。

dstat 1 10    #间隔1秒输出10组数据

可以看到当 wai（iowait）升高时磁盘请求 read 都会很大，说明 iowait 的升高和磁盘的读请求有关。接下来分析到底时哪个进程在读磁盘。
之前 top 查看的处于 D 状态的进程号，用 pidstat -d -p XXX 展示进程的 I/O 统计数据。发现处于 D 状态的进程都没有任何读写操作。在用 pidstat -d 查看所有进程的 I/O 统计数据，看到 app 进程在进行磁盘读操作，每秒读取 32MB 的数据。进程访问磁盘必须使用系统调用处于内核态，接下来重点就是找到 app 进程的系统调用。

sudo strace -p XXX #对app进程调用进行跟踪

报错没有权限，因为已经时 root 权限了。所以遇到这种情况，首先要检查进程状态是否正常。 ps 命令查找该进程已经处于 Z 状态，即僵尸进程。
这种情况下 top pidstat 之类的工具无法给出更多的信息，此时像第 5 篇一样，用 perf record -d 和 perf report 进行分析，查看 app 进程调用栈。
看到 app 确实在通过系统调用 sys_read() 读取数据，并且从 new_sync_read 和 blkdev_direct_IO 看出进程时进行直接读操作，请求直接从磁盘读，没有通过缓存导致 iowait 升高。
通过层层分析后，root cause 是 app 内部进行了磁盘的直接 I/O。然后定位到具体代码位置进行优化即可。

僵尸进程

上述优化后 iowait 显著下降，但是僵尸进程数量仍旧在增加。首先要定位僵尸进程的父进程，通过 pstree -aps XXX，打印出该僵尸进程的调用树，发现父进程就是 app 进程。
查看 app 代码，看看子进程结束的处理是否正确（是否调用 wait()/waitpid(), 有没有注册 SIGCHILD 信号的处理函数等）。
碰到 iowait 升高时，先用 dstat pidstat 等工具确认是否存在磁盘 I/O 问题，再找是哪些进程导致 I/O，不能用 strace 直接分析进程调用时可以通过 perf 工具分析。
对于僵尸问题，用 pstree 找到父进程，然后看源码检查子进程结束的处理逻辑即可。

CPU 性能指标

CPU 使用率
- 用户 CPU 使用率, 包括用户态 (user) 和低优先级用户态(nice). 该指标过高说明应用程序比较繁忙.
- 系统 CPU 使用率, CPU 在内核态运行的时间百分比 (不含中断). 该指标高说明内核比较繁忙.
- 等待 I/O 的 CPU 使用率, iowait, 该指标高说明系统与硬件设备 I/O 交互时间比较长.
- 软 / 硬中断 CPU 使用率, 该指标高说明系统中发生大量中断.
- steal CPU / guest CPU, 表示虚拟机占用的 CPU 百分比.
平均负载理想情况下平均负载等于逻辑 CPU 个数, 表示每个 CPU 都被充分利用. 若大于则说明系统负载较重.
进程上下文切换包括无法获取资源的自愿切换和系统强制调度时的非自愿切换. 上下文切换本身是保证 Linux 正常运行的一项核心功能. 过多的切换则会将原本运行进程的 CPU 时间消耗在寄存器, 内核占及虚拟内存等数据保存和恢复上
CPU 缓存命中率 CPU 缓存的复用情况, 命中率越高性能越好. 其中 L1/L2 常用在单核,L3 则用在多核中

性能工具

平均负载案例
- 先用 uptime 查看系统平均负载
- 判断负载在升高后再用 mpstat 和 pidstat 分别查看每个 CPU 和每个进程 CPU 使用情况. 找出导致平均负载较高的进程.
上下文切换案例
- 先用 vmstat 查看系统上下文切换和中断次数
- 再用 pidstat 观察进程的自愿和非自愿上下文切换情况
- 最后通过 pidstat 观察线程的上下文切换情况
进程 CPU 使用率高案例
- 先用 top 查看系统和进程的 CPU 使用情况, 定位到进程
- 再用 perf top 观察进程调用链, 定位到具体函数
系统 CPU 使用率高案例
- 先用 top 查看系统和进程的 CPU 使用情况,top/pidstat 都无法找到 CPU 使用率高的进程
- 重新审视 top 输出
- 从 CPU 使用率不高, 但是处于 Running 状态的进程入手
- perf record/report 发现短时进程导致 (execsnoop 工具)
不可中断和僵尸进程案例
- 先用 top 观察 iowait 升高, 发现大量不可中断和僵尸进程
- strace 无法跟踪进程系统调用
- perf 分析调用链发现根源来自磁盘直接 I/O
软中断案例
- top 观察系统软中断 CPU 使用率高
- 查看 /proc/softirqs 找到变化速率较快的几种软中断
- sar 命令发现是网络小包问题
- tcpdump 找出网络帧的类型和来源, 确定 SYN FLOOD 攻击导致

根据不同的性能指标来找合适的工具:

在生产环境中往往开发者没有权限安装新的工具包, 只能最大化利用好系统中已经安装好的工具. 因此要了解一些主流工具能够提供哪些指标分析.

先运行几个支持指标较多的工具, 如 top/vmstat/pidstat, 根据它们的输出可以得出是哪种类型的性能问题. 定位到进程后再用 strace/perf 分析调用情况进一步分析. 如果是软中断导致用 /proc/softirqs

CPU 优化

应用程序优化
- 编译器优化: 编译阶段开启优化选项, 如 gcc -O2
- 算法优化
- 异步处理: 避免程序因为等待某个资源而一直阻塞, 提升程序的并发处理能力. (将轮询替换为事件通知)
- 多线程代替多进程: 减少上下文切换成本
- 善用缓存: 加快程序处理速度
系统优化
- CPU 绑定: 将进程绑定要 1 个 / 多个 CPU 上, 提高 CPU 缓存命中率, 减少 CPU 调度带来的上下文切换
- CPU 独占: CPU 亲和性机制来分配进程
- 优先级调整: 使用 nice 适当降低非核心应用的优先级
- 为进程设置资源显示: cgroups 设置使用上限, 防止由某个应用自身问题耗尽系统资源
- NUMA 优化: CPU 尽可能访问本地内存
- 中断负载均衡: irpbalance, 将中断处理过程自动负载均衡到各个 CPU 上
TPS、QPS、系统吞吐量的区别和理解
- QPS (Queries Per Second) 每秒查询率, 一台服务器每秒能够响应的查询次数.
- TPS (Transactions Per Second) 每秒事务数, 软件测试的结果.
  - 用户请求服务器
  - 服务器内部处理
  - 服务器返回给客户 QPS 类似 TPS, 但是对于一个页面的访问形成一个 TPS, 但是一次页面请求可能包含多次对服务器的请求, 可能计入多次 QPS
- 系统吞吐量, 包括几个重要参数:
  - QPS(TPS)
  - 并发数
  - 响应时间 QPS(TPS)= 并发数 / 平均相应时间

内存

Linux 内存是怎么工作的

内存映射

大多数计算机用的主存都是动态随机访问内存 (DRAM)，只有内核才可以直接访问物理内存。Linux 内核给每个进程提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样进程就可以很方便的访问内存 (虚拟内存)。
虚拟地址空间的内部分为内核空间和用户空间两部分，不同字长的处理器地址空间的范围不同。32 位系统内核空间占用 1G，用户空间占 3G。 64 位系统内核空间和用户空间都是 128T，分别占内存空间的最高和最低处，中间部分为未定义。
并不是所有的虚拟内存都会分配物理内存，只有实际使用的才会。分配后的物理内存通过内存映射管理。为了完成内存映射，内核为每个进程都维护了一个页表，记录虚拟地址和物理地址的映射关系。页表实际存储在 CPU 的内存管理单元 MMU 中，处理器可以直接通过硬件找出要访问的内存。
当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存，更新进程页表，再返回用户空间恢复进程的运行。
MMU 以页为单位管理内存，页大小 4KB。为了解决页表项过多问题 Linux 提供了多级页表和 HugePage 的机制。

虚拟内存空间分布

用户空间内存从低到高是五种不同的内存段：

只读段 代码和常量等
数据段 全局变量等
堆动态分配的内存，从低地址开始向上增长
文件映射 动态库、共享内存等，从高地址开始向下增长
栈包括局部变量和函数调用的上下文等，栈的大小是固定的。一般 8MB

内存分配与回收

分配

malloc 对应到系统调用上有两种实现方式：

brk()针对小块内存 (<128K)，通过移动堆顶位置来分配。内存释放后不立即归还内存，而是被缓存起来。
**mmap()** 针对大块内存 (>128K)，直接用内存映射来分配，即在文件映射段找一块空闲内存分配。

前者的缓存可以减少缺页异常的发生，提高内存访问效率。但是由于内存没有归还系统，在内存工作繁忙时，频繁的内存分配 / 释放会造成内存碎片。
后者在释放时直接归还系统，所以每次 mmap 都会发生缺页异常。在内存工作繁忙时，频繁内存分配会导致大量缺页异常，使内核管理负担增加。
上述两种调用并没有真正分配内存，这些内存只有在首次访问时，才通过缺页异常进入内核中，由内核来分配

回收

内存紧张时，系统通过以下方式来回收内存：

回收缓存： LRU 算法回收最近最少使用的内存页面；
回收不常访问内存：把不常用的内存通过交换分区写入磁盘
杀死进程： OOM 内核保护机制（进程消耗内存越大 oom_score 越大，占用 CPU 越多 oom_score 越小，可以通过 /proc 手动调整 oom_adj）

echo -16 > /proc/$(pidof XXX)/oom_adj

如何查看内存使用情况

free 来查看整个系统的内存使用情况
top/ps 来查看某个进程的内存使用情况

VIRT 进程的虚拟内存大小
RES 常驻内存的大小，即进程实际使用的物理内存大小，不包括 swap 和共享内存
SHR 共享内存大小，与其他进程共享的内存，加载的动态链接库以及程序代码段
%MEM 进程使用物理内存占系统总内存的百分比

怎样理解内存中的 Buffer 和 Cache？

buffer 是对磁盘数据的缓存，cache 是对文件数据的缓存，它们既会用在读请求也会用在写请求中

如何利用系统缓存优化程序的运行效率

缓存命中率

缓存命中率是指直接通过缓存获取数据的请求次数，占所有请求次数的百分比。命中率越高说明缓存带来的收益越高，应用程序的性能也就越好。
安装 bcc 包后可以通过 cachestat 和 cachetop 来监测缓存的读写命中情况。
安装 pcstat 后可以查看文件在内存中的缓存大小以及缓存比例

#首先安装Go
export GOPATH=~/go
export PATH=~/go/bin:$PATH
go get golang.org/x/sys/unix
go ge github.com/tobert/pcstat/pcstat

dd 缓存加速

dd if=/dev/sda1 of=file bs=1M count=512 #生产一个512MB的临时文件
echo 3 > /proc/sys/vm/drop_caches #清理缓存
pcstat file #确定刚才生成文件不在系统缓存中，此时cached和percent都是0
cachetop 5
dd if=file of=/dev/null bs=1M #测试文件读取速度
#此时文件读取性能为30+MB/s，查看cachetop结果发现并不是所有的读都落在磁盘上，读缓存命中率只有50%。
dd if=file of=/dev/null bs=1M #重复上述读文件测试
#此时文件读取性能为4+GB/s，读缓存命中率为100%
pcstat file #查看文件file的缓存情况，100%全部缓存

O_DIRECT 选项绕过系统缓存

cachetop 5
sudo docker run --privileged --name=app -itd feisky/app:io-direct
sudo docker logs app #确认案例启动成功
#实验结果表明每读32MB数据都要花0.9s，且cachetop输出中显示1024次缓存全部命中

但是凭感觉可知如果缓存命中读速度不应如此慢，读次数时 1024，页大小为 4K，五秒的时间内读取了 1024*4KB 数据，即每秒 0.8MB，和结果中 32MB 相差较大。说明该案例没有充分利用缓存，怀疑系统调用设置了直接 I/O 标志绕过系统缓存。因此接下来观察系统调用.

strace -p $(pgrep app)
#strace 结果可以看到openat打开磁盘分区/dev/sdb1，传入参数为O_RDONLY|O_DIRECT

这就解释了为什么读 32MB 数据那么慢，直接从磁盘读写肯定远远慢于缓存。找出问题后我们再看案例的源代码发现 flags 中指定了直接 IO 标志。删除该选项后重跑，验证性能变化。

内存泄漏，如何定位和处理？

对应用程序来说，动态内存的分配和回收是核心又复杂的一个逻辑功能模块。管理内存的过程中会发生各种各样的“事故”：

没正确回收分配的内存，导致了泄漏
访问的是已分配内存边界外的地址，导致程序异常退出

内存的分配与回收

虚拟内存分布从低到高分别是只读段，数据段，堆，内存映射段，栈五部分。其中会导致内存泄漏的是：

堆：由应用程序自己来分配和管理，除非程序退出这些堆内存不会被系统自动释放。
内存映射段：包括动态链接库和共享内存，其中共享内存由程序自动分配和管理

内存泄漏的危害比较大，这些忘记释放的内存，不仅应用程序自己不能访问，系统也不能把它们再次分配给其他应用。 内存泄漏不断累积甚至会耗尽系统内存.

如何检测内存泄漏

预先安装 systat，docker，bcc

sudo docker run --name=app -itd feisky/app:mem-leak
sudo docker logs app
vmstat 3

可以看到 free 在不断下降，buffer 和 cache 基本保持不变。说明系统的内存一致在升高。但并不能说明存在内存泄漏。此时可以通过 memleak 工具来跟踪系统或进程的内存分配 / 释放请求

/usr/share/bcc/tools/memleak -a -p $(pidof app)

从 memleak 输出可以看到，应用在不停地分配内存，并且这些分配的地址并没有被回收。通过调用栈看到是 fibonacci 函数分配的内存没有释放。定位到源码后查看源码来修复增加内存释放函数即可.

为什么系统的 Swap 变高

系统内存资源紧张时通过内存回收和 OOM 杀死进程来解决。其中可回收内存包括：

缓存 / 缓冲区，属于可回收资源，在文件管理中通常叫做文件页
- 被应用程序修改过暂时没写入磁盘的数据 (脏页)，要先写入磁盘然后才能内存释放
  - 在应用程序中通过 fsync 将脏页同步到磁盘
  - 交给系统，内核线程 pdflush 负责这些脏页的刷新
内存映射获取的文件映射页，也可以被释放掉，下次访问时从文件重新读取

对于程序自动分配的堆内存，也就是我们在内存管理中的匿名页，虽然这些内存不能直接释放，但是 Linux 提供了 Swap 机制将不常访问的内存写入到磁盘来释放内存，再次访问时从磁盘读取到内存即可。

Swap 原理

Swap 本质就是把一块磁盘空间或者一个本地文件当作内存来使用，包括换入和换出两个过程：

换出：将进程暂时不用的内存数据存储到磁盘中，并释放这些内存
换入：进程再次访问内存时，将它们从磁盘读到内存中

Linux 如何衡量内存资源是否紧张？

直接内存回收 新的大块内存分配请求，但剩余内存不足。此时系统会回收一部分内存；
kswapd0 内核线程定期回收内存。为了衡量内存使用情况，定义了 pages_min,pages_low,pages_high 三个阈值，并根据其来进行内存的回收操作。
- 剩余内存 < pages_min，进程可用内存耗尽了，只有内核才可以分配内存
- pages_min < 剩余内存 < pages_low, 内存压力较大，kswapd0 执行内存回收，直到剩余内存 > pages_high
- pages_low < 剩余内存 < pages_high，内存有一定压力，但可以满足新内存请求
- 剩余内存 > pages_high，说明剩余内存较多，无内存压力 pages_low = pages_min 5 / 4 pages_high = pages_min 3 / 2

NUMA 与 SWAP

很多情况下系统剩余内存较多，但 SWAP 依旧升高，这是由于处理器的 NUMA 架构。
在 NUMA 架构下多个处理器划分到不同的 Node，每个 Node 都拥有自己的本地内存空间。在分析内存的使用时应该针对每个 Node 单独分析

numactl --hardware #查看处理器在Node的分布情况，以及每个Node的内存使用情况

内存三个阈值可以通过 /proc/zoneinfo 来查看，该文件中还包括活跃和非活跃的匿名页 / 文件页数。
当某个 Node 内存不足时，系统可以从其他 Node 寻找空闲资源，也可以从本地内存中回收内存。通过 /proc/sys/vm/zone_raclaim_mode 来调整。

0 表示既可以从其他 Node 寻找空闲资源，也可以从本地回收内存
1，2，4 表示只回收本地内存，2 表示可以会回脏数据回收内存，4 表示可以用 Swap 方式回收内存。

swappiness

在实际回收过程中 Linux 根据 /proc/sys/vm/swapiness 选项来调整使用 Swap 的积极程度，从 0-100，数值越大越积极使用 Swap，即更倾向于回收匿名页；数值越小越消极使用 Swap，即更倾向于回收文件页。
注意：这只是调整 Swap 积极程度的权重，即使设置为 0，当剩余内存 + 文件页小于页高阈值时，还是会发生 Swap。

Swap 升高时如何定位分析

free #首先通过free查看swap使用情况，若swap=0表示未配置Swap
#先创建并开启swap
fallocate -l 8G /mnt/swapfile
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile

free #再次执行free确保Swap配置成功

dd if=/dev/sda1 of=/dev/null bs=1G count=2048 #模拟大文件读取
sar -r -S 1  #查看内存各个指标变化 -r内存 -S swap
#根据结果可以看出，%memused在不断增长，剩余内存kbmemfress不断减少，缓冲区kbbuffers不断增大，由此可知剩余内存不断分配给了缓冲区
#一段时间之后，剩余内存很小，而缓冲区占用了大部分内存。此时Swap使用之间增大，缓冲区和剩余内存只在小范围波动

停下sar命令
cachetop5 #观察缓存
#可以看到dd进程读写只有50%的命中率，未命中数为4w+页，说明正式dd进程导致缓冲区使用升高
watch -d grep -A 15 ‘Normal’ /proc/zoneinfo #观察内存指标变化
#发现升级内存在一个小范围不停的波动，低于页低阈值时会突然增大到一个大于页高阈值的值

说明剩余内存和缓冲区的波动变化正是由于内存回收和缓存再次分配的循环往复。有时候 Swap 用的多，有时候缓冲区波动更多。此时查看 swappiness 值为 60，是一个相对中和的配置，系统会根据实际运行情况来选去合适的回收类型.

如何“快准狠”找到系统内存存在的问题

内存性能指标

系统内存指标

已用内存 / 剩余内存
共享内存（tmpfs 实现）
可用内存：包括剩余内存和可回收内存
缓存：磁盘读取文件的页缓存，slab 分配器中的可回收部分
缓冲区：原始磁盘块的临时存储，缓存将要写入磁盘的数据

进程内存指标

虚拟内存： 5 大部分
常驻内存：进程实际使用的物理内存，不包括 Swap 和共享内存
共享内存：与其他进程共享的内存，以及动态链接库和程序的代码段
Swap 内存：通过 Swap 换出到磁盘的内存

缺页异常

可以直接从物理内存中分配，次缺页异常
需要磁盘 IO 介入 (如 Swap)，主缺页异常。此时内存访问会慢很多

内存性能工具