Linux性能优化
欢迎你来读这篇博客，这篇博客主要是关于Linux性能优化。
其中包括了关于我的见解和收集的知识分享。
序言
性能优化指标是什么？
当看到性能指标时，你会首先想到什么呢?我相信“高并发”和“响应快”一定是最先出现在你脑海里的两个词，而它们也正对应着性能优化的两个核心指标“吞吐”和“延时”。这两个指标是从应用负载的视角来考察性能，直接影响了产品终端的用户体验。跟它们对应的是从系统资源的视角出发的指标，比如资源使用率、饱和度等。
随着应用负载的增加，系统资源的使用也会升高，甚至达到极限。而性能问题的本质，就是系统资源已经达到瓶颈，但请求的处理却还不够快，无法支撑更多的请求。
性能分析，其实就是找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。这包含了一系列的步骤，比如下面这六个步骤。
- 选择指标评估应用程序和系统的性能，
- 为应用程序和系统设置性能目标;
- 进行性能基准测试;
- 性能分析定位瓶颈，
- 优化系统和应用程序
- 性能监控和告警。
前置基础
- Linux基本了解
- 熟悉Linux命令、软件安装
- 熟悉编程开发、shell语言
目标：建立整体系统性能的全局观
- 理解最基本的几个系统知识原理;
- 掌握必要的性能工具;
- 通过实际的场景演练，贯穿不同的组件，
核心内容
- CPU
- 内存
- 网络
- 磁盘IO
- 性能测试
- 性能监控
- 架构设计
- 应用程序
- Linux内核
- 文件系统
如何学习
- 先把书读薄，再读厚，再读薄
- 边学边实践
- 勤思考，多反思，善总结，多问为什么
正文
到底应该怎么理解“平均负载”
平均负载
每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令，来了解系统的负载情况。比如像下面这样，我在命令行里输入了uptime命令，系统也随即给出了结果。
1 | |
简单来说，平均负载是指单位时间内，系统处于 可运行状态 和 不可中断状态 的平均进程数，也就是 平均活跃进程数，它和CPU使用率并没有直接关系。
Load Average = (运行队列中的进程数量) / 系统的CPU数量。
可运行状态的进程，是指正在使用CPU或者正在等待CPU的进程，也就是我们常用ps命令看到的，处于R状态（Running 或 Runnable）的进程。
不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的I/O响应，也就是我们在ps命令中看到的D状态（Uninterruptible
Sleep，也称为Disk Sleep）的进程。
比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。
所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
可以简单理解为，平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。
既然平均的是活跃进程数，那么最理想的，就是每个CPU上都刚好运行着一个进程，这样每个CPU都得到了充分利用。比如当平均负载为2时，意味着什么呢？
在只有2个CPU的系统上，意味着所有的CPU都刚好被完全占用。
在4个CPU的系统上，意味着CPU有50%的空闲。
而在只有1个CPU的系统中，则意味着有一半的进程竞争不到CPU。
平均负载为多少时合理？
平均负载最理想的情况是等于 CPU个数。所以在评判平均负载时， 首先你要知道系统有几个 CPU，这可以通过 top 命令或者从文件
/proc/cpuinfo 中读取，比如：
1 | |
有了CPU 个数，我们就可以判断出，当平均负载比 CPU 个数还大的时候，系统已经出现了过载。
不过，且慢，新的问题又来了。我们在例子中可以看到，平均负载有三个数值，到底该参考哪一个呢？
实际上，都要看。三个不同时间间隔的平均值，其实给我们提供了，分析 系统负载趋势 的数据来源，让我们能更全面、更立体地理解目前的负载状况。
如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
但如果1分钟的值远小于15 分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。
反过来，如果1分钟的值远大于 15
分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。
那么，在实际生产环境中，平均负载多高时，需要我们重点关注呢？
在我看来， 当平均负载高于 CPU 数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
但70%这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查。
平均负载与CPU使用率
平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了 正在使用 CPU 的进程，还包括 等待 CPU 和 等待
I/O 的进程。
而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：
- CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
- I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
- 大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。
案例1 Cpu密集
先用 uptime 命令，看一下测试前的平均负载情况：
1 | |
首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
1 | |
接着，在第二个终端运行uptime查看平均负载的变化情况：
1 | |
最后，在第三个终端运行mpstat查看 CPU 使用率的变化情况：
1 | |
从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait
只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。
那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询：
1 | |
从这里可以明显看到，stress进程的CPU使用率为100%。
案例2 IO密集
首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：
1 | |
还是在第二个终端运行uptime查看平均负载的变化情况：
1 | |
然后，第三个终端运行mpstat查看 CPU 使用率的变化情况：
1 | |
从这里可以看到，1 分钟的平均负载会慢慢增加到 1.06，其中一个 CPU 的系统CPU使用率升高到了 23.87，而 iowait 高达
67.53%。这说明，平均负载的升高是由于 iowait 的升高。
那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询：
1 | |
可以发现，还是 stress 进程导致的
场景三 大量进程的场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
比如，我们还是使用 stress，但这次模拟的是 8 个进程：
1 | |
由于系统只有 2 个CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达7.97：
1 | |
接着再运行pidstat来看一下进程的情况：
1 | |
可以看出，8 个进程在争抢 2 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致
CPU 过载。
小结
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：
平均负载高有可能是 CPU 密集型进程导致的；
平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。
经常说的 CPU 上下文切换是什么意思？
杂谈
排查思路
- 先去看系统负载、系统监控大盘 top htop
- 平均负载过高，看一下什么资源紧张 top
- 如果CPU没问题，看一下内存 cache buffer free
- 然后看磁盘 iostat
- 然后看带宽 iftop
- 具体应用看一下配置参数
- 外部系统，如数据库、缓存、存储
参考资料
启示录
富贵岂由人，时会高志须酬。
能成功于千载者，必以近察远。