linux性能调优

Linux 性能工具把观察到的性能问题跟系统原理关联起来，特别是把系统从应用程序、库函数、系统调用、再到内核和硬件等不同的层级贯穿起来。

 

这些问题或场景。

1·流量高峰期，服务器 CPU 使用率过高报警，登录 Linux 上去 top 完，进一步定位，是系统 CPU 资源太少，或者程序并发部分有问题。

 

\2. 系统没有跑吃内存的程序， free 命令之后，发现系统没有内存了，哪里占用了内存。

 

\3. 收到 Zabbix 告警发现某台存放监控数据的数据库主机的 iowait 较高。

 

主要是因为性能优化是个系统工程，总是牵一发而动全身。它涉及了从程序设计、算法分析、编程语言，再到系统、存储、网络等各种底层基础设施的方方面面。每一个组件都有可能出问题，而且很有可能多个组件同时出问题。

从资源使用的视角出发，分析各种 Linux 资源可能会碰到的性能问题，包括 CPU 性能、磁盘 I/O 性能、内存性能以及网络性能。

 

性能优化的第一步，了解“性能指标”这个概念。

性能优化的两个核心指标——“吞吐”和“延时”。这两个指标是从应用负载的视角来考察性能，直接影响了产品终端的用户体验。跟它们对应的，是从系统资源的视角出发的指标，比如资源使用率、饱和度等。

 

随着应用负载的增加，系统资源的使用也会升高，甚至达到极限。而性能问题的本质，就是系统资源已经达到瓶颈，但请求的处理却还不够快，无法支撑更多的请求。

 

找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。

选择指标评估应用程序和系统的性能；

为应用程序和系统设置性能目标；

进行性能基准测试；

性能分析定位瓶颈；

优化系统和应用程序；

性能监控和警

图是 Linux 性能分析最重要的参考资料之一，在 Linux 不同子系统出现性能问题后，应该用什么样的工具来观测和分析。

 

有监控的情况下，首先去监控大盘，有没有异常报警，如果初期还没有监控的情况按照下面步骤去系统层面有没有异常 1、系统的平均负载，使用top或者htop命令查看,平均负载体现的是系统的一个整体情况应该是cpu、内存、磁盘性能的一个综合，一般是平均负载的值大于机器cpu的核数，说明机器资源已经紧张了 2、平均负载高了以后，在top中看cpu每个核的使用情况，如果占比很高，瓶颈是cpu,什么进程导致的 3、如果cpu没有问题，看内存，用free去查看内存的是用情况，但不直接看他剩余了多少，还要结合看看cache和buffer，然后再具体是什么进程占用了过高的内存，是用top去排序 4、内存没有问题的话就要去看磁盘了，磁盘iostat去查看 5、还有就是带宽问题，一般会用iftop去查看流量情况，流量是否超过的机器给定的带宽 6、涉及到具体应用的话，就要根据具体应用的设定参数来查看，比如连接数是否查过设定值等 7、如果系统层各个指标查下来都没有发现异常，那么就要考虑外部系统了，比如数据库、缓存、存储等

 

发现系统变慢时，执行 top 或者 uptime 命令，来了解系统的负载情况

uptime

12:07:36 up 5 days, 19:35, 2 users, load average: 0.10, 0.10, 0.09

//当前时间up 5 days, 19:35 //系统运行时间1 user //正在登录用户数 1分钟5分钟15分钟平均负载（Load Average）。

 

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

可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。

不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

平均负载最理想的情况是等于 CPU 个数。在评判平均负载时，要知道系统有几个 CPU，这可以通过 top 命令或者从文件 /proc/cpuinfo 中读取

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

有了 CPU 个数，可以判断出，当平均负载比 CPU 个数还大的时候，系统已经出现了过载。

三个不同时间间隔的平均值，分析系统负载趋势的数据来源，能更全面、更立体地理解目前的负载状况。

当平均负载高于 CPU 数量 70% 的时候，分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。

 

*平均负载与 CPU 使用率*

平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。

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

 

以三个示例分别来看这三种情况，并用 iostat、mpstat、pidstat 等工具，找出平均负载升高的根源。预先安装 stress 和 sysstat 包，如 apt install stress sysstat。

 

mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。

pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

每个场景都需要开三个终端，登录到同一台 Linux 机器中。默认以 root 用户运行。

*场景一：CPU 密集型进程*

 

 

从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.20，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。

可以使用 pidstat 来查询：可以明显看到，stress 进程的 CPU 使用率为 99.8%。

 

*场景二：I/O 密集型进程*

首先还是运行 stress 命令，这次模拟 I/O

 

 

从这里可以看到，1 分钟的平均负载会慢慢增加到 1.12，其中一个 CPU 的系统 CPU 使用率升高到了 27.79，而 iowait 达 33.25%。这说明，平均负载的升高是由于 iowait 的升高。

用 pidstat 来查询：导致 iowait 变高。

可以发现， stress 进程导致的。

*场景三：大量进程的场景*

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。

 

 

 

 

 

可以看出，8 个进程在争抢 2个 CPU,这些超出 CPU 计算能力的进程，最终导致 CPU 使用率356%过载。

平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。

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

*CPU 上下文切换*

进程在竞争 CPU 的时候并没有真正运行，CPU 上下文切换导致系统的负载升高，Linux 是一个多任务操作系统，它支持远大于 CPU 数量的任务同时运行。当然，这些任务实际上并不是真的在同时运行，而是因为系统在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行。每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，需要系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。

 

CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。而程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。

 

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

保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来。这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。

 

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

 

*进程上下文切换*

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

内核空间（Ring 0）具有最高权限，可以直接访问所有资源；用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源

进程既可以在用户空间运行，又可以在内核空间中运行。进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态。

从用户态到内核态的转变，需要通过系统调用来完成。比如，当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件。

 

CPU 寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU 寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。而系统调用结束后，CPU 寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程。所以，一次系统调用的过程，其实是发生了两次 CPU 上下文切换。

 

系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源，也不会切换进程。

所以，系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上，系统调用过程中，CPU 的上下文切换还是无法避免的。

 

进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以，进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。因此，进程的上下文切换就比系统调用时多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。

 

根据 Tsuna 的测试报告，每次上下文切换都需要几十纳秒到数微秒的 CPU 时间。这个时间还是相当可观的，特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。导致平均负载升高的一个重要因素。

 

*线程上下文切换*

线程与进程最大的区别在于，线程是调度的基本单位，而进程则是资源拥有的基本单位。内核中的任务调度，实际上的调度对象是线程；进程只是给线程提供了虚拟内存、全局变量等资源。

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

 

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

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

*线程的上下文切换其实就可以分为两种情况：*

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

第二种，前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据。虽然同为上下文切换，但同进程内的线程切换，要比多进程间的切换消耗更少的资源，也正是多线程代替多进程的一个优势。

 

*中断上下文切换*

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

跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。中断上下文，只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等。

 

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

 

另外，跟进程上下文切换一样，中断上下文切换也需要消耗 CPU，切换次数过多也会耗费大量的 CPU，甚至严重降低系统的整体性能。所以，当发现中断次数过多时，就需要注意去排查它是否会给系统带来严重的性能问题。

 

*可以使用 vmstat 这个工具，来查询系统的上下文切换情况。*

 

特别关注的四列内容：

cs（context switch）是每秒上下文切换的次数。

in（interrupt）则是每秒中断的次数。

r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。

b（Blocked）则是处于不可中断睡眠状态的进程数。

这个例子中的上下文切换次数 cs 是 783 次，而系统中断次数 in 则是 268次，而就绪队列长度 r 和不可中断状态进程数 b 都是 0。

 

vmstat 给出了系统总体的上下文切换情况，要想查看每个进程的详细情况，就需要使用前面提到过的 pidstat 了。给它加上 -w 选项，可以查看每个进程上下文切换的情况了。

 

一个是 cswch ，表示每秒自愿上下文切换（voluntary context switches）的次数，另一个则是 nvcswch ，表示每秒非自愿上下文切换（non voluntary context switches）的次数。

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

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

 

上下文切换频率是多少次才算正常呢 将使用 sysbench 来模拟系统多线程调度切换的情况。

sysbench 是一个多线程的基准测试工具，一般用来评估不同系统参数下的数据库负载情况。在这次案例中，把它当成一个异常进程来看，作用是模拟上下文切换过多的问题。默认以 root 用户运行。

 

现在的上下文切换次数 cs 是 12，而中断次数 in 是 20，r 和 b 都是 0。并没有运行其他任务，所以它们就是空闲系统的上下文切换次数。

 

 

*操作和分析*

以10个线程运行5分钟的基准测试，模拟多线程切换的问题

sysbench --num-threads=10 --max-time=300 --max-requests=10000000 --test=threads run

 

在第二个终端运行 vmstat ，观察上下文切换情况：

 

可以发现，cs 列的上下文切换次数从之前的 12 骤然上升到了 413 万。同时，其他几个指标：r 列：就绪队列的长度已经到了 8，远超过了系统 CPU 的个数 2，所以肯定会有大量的 CPU 竞争。us（user）和 sy（system）列：这两列的 CPU 使用率加起来上升到了 100%，其中系统 CPU 使用率，也就是 sy 列高达 84%，说明 CPU 主要是被内核占用了。in 列：中断次数也上升到了 2万左右，说明中断处理也是个潜在的问题。综合这几个指标，知道系统的就绪队列过长，是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。是什么进程导致了这些问题呢，在第三个终端再用 pidstat 看一下， CPU 和进程上下文切换的情况：

从 pidstat 的输出可以发现，CPU 使用率的升高是 sysbench 导致的， CPU 使用率已经达到了 121%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd。

pidstat 输出的上下文切换次数，加起来几百，比 vmstat 的 139 万明显小.

系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。

在第三个终端再用 pidstat 来看一下， CPU 和进程上下文切换的情况：

pidstat -wt 1

 

sysbench 进程（是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。上下文切换是主要原因，过多的 sysbench 线程。

 

前面在观察系统指标时，中断次数也上升到了 1 万，中断只发生在内核态，pidstat 是一个进程的性能分析工具，并不提供任何关于中断的详细信息。

从 /proc/interrupts 这个只读文件中读取。/proc 是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分，提供了一个只读的中断使用情况。

在第三个终端里， Ctrl+C 停止刚才的 pidstat 命令

-d 参数表示高亮显示变化的区域$ watch -d cat /proc/interrupts

 

可以发现，变化速度最快的是重调度中断（RES），这个中断类型表示，唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统（SMP）中，调度器用来分散任务到不同 CPU 的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）。

这里的中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的。

正常每秒上下文切换取决于系统本身的 CPU 性能如果系统的上下文切换次数比较稳定，那么从数百到一万以内，算是正常的。当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就可能已经出现了性能问题。

自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题；

非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈；

中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。

描述系统的 CPU 性能指标是CPU 使用率。

CPU 使用率是单位时间内 CPU 使用情况的统计，以百分比的方式展示。

Linux 一个多任务操作系统，将每个 CPU 的时间划分为很短的时间片，再通过调度器轮流分配给各个任务使用，因此多任务同时运行。

Linux 通过 /proc 虚拟文件系统，向用户空间提供了系统内部状态的信息，/proc/stat 提供的就是系统的 CPU 和任务统计信息。

第一列表示的是 CPU 编号，cpu0、cpu1 ，第一行没有编号的 cpu ，表示的是所有 CPU 的累加。其他列则表示不同场景下 CPU 的累加节拍数，它的单位是 USER_HZ，也就是 10 ms（1/100 秒），是不同场景下的 CPU 时间。

top 显示了系统总体的 CPU 和内存使用情况，以及各个进程的资源使用情况。

ps 显示了每个进程的资源使用情况。

 

 

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 时间。

 

top 没有细分进程的用户态 CPU 和内核态 CPU。

 

用户态 CPU 使用率 （%usr）；

内核态 CPU 使用率（%system）；

运行虚拟机 CPU 使用率（%guest）；

等待 CPU 使用率（%wait）；

总的 CPU 使用率（%CPU）。

因为 GDB 调试程序的过程会中断程序运行，这在线上环境是不允许的，使用 perf 分析 CPU 性能问题

 

 

输出结果中，第一行包含三个数据，分别是采样数（Samples）、事件类型（event）和事件总数量（Event count）。例子中，perf 总共采集了 94k个 CPU 时钟事件，而总事件数则为 1762019083

第一列 Overhead ，是该符号的性能事件在所有采样中的比例，用百分比来表示。

第二列 Shared ，是该函数或指令所在的动态共享对象（Dynamic Shared Object），如内核、进程名、动态链接库名、内核模块名等。

第三列 Object ，是动态共享对象的类型。

最后一列 Symbol 是符号名，是函数名。当函数名未知时，用十六进制的地址来表示。

perf top 实时展示了系统的性能信息，缺点是并不保存数据，无法用于离线或者后续的分析。而perf record 则提供了保存数据的功能，保存后的数据，用 perf report 解析展示。

*以 Nginx + PHP 的 Web 服务为例*

案例要用到两台虚拟机，如下图所示：

 

一台用作 Web 服务器，来模拟性能问题；另一台用作 Web 服务器的客户端，来给 Web 服务增加压力请求。使用两台虚拟机是为了相互隔离，避免“交叉感染”。

打开两个终端，分别 SSH 登录到两台机器上，并安装上述工具，sudo su root 命令切换到 root 用户。

第一个终端，执行下面的命令运行 Nginx 和 PHP 应用：

docker run --name nginx -p 10000:80 -itd feisky/nginx:sp

docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:sp

在第二个终端，使用 curl 访问 http://[VM1 的 IP]:10000，确认 Nginx 已正常启动。

curl http://192.168.0.187:10000/ It works!

测试一下这个 Nginx 服务的性能。在第二个终端运行下面的 ab 命令。并发 100 个请求测试 Nginx 性能，总共测试 1000 个请求。

ab -c 100 -n 1000 http://192.168.0.187:10000/

 

Nginx 能承受的每秒平均请求数，有 11.85多一点。

第二个终端，将测试的并发请求数改成 5，同时把请求时长设置为 10 分钟（-t 600）。第一个终端使用性能分析工具时， Nginx 的压力还是继续的。Top查看

 

 

CPU 使用率的进程40.4%，再看系统 CPU 使用率（ %Cpu ）这一行，，系统的整体 CPU 使用率是比较高：用户 CPU 使用率（us）已经到了 98.7%，系统 CPU 为 1.3%，空闲 CPU （id）则 0%。

 

所有进程的 CPU 使用率也都不高，最高的 smp 有 3.9% 。

 

系统中有几个 php-fpm 进程的 CPU 使用率加起来接近 200%； CPU 的用户使用率（us）也已经超过了 99%，接近饱和。这样可以确认，正是用户空间的 php-fpm 进程，导致 CPU 使用率骤升。

php-fpm 的哪个函数导致了 CPU 使用率升高，用 perf 在第一个终端运行下面的 perf 命令：

perf top -g -p 29120

按方向键切换到 php-fpm，再按下回车键展开 php-fpm 的调用关系，调用关系最终到了 sqrt 和 add_function。需要从这两个函数入手了。

从容器phpfpm中将PHP源码拷贝出来$ docker cp phpfpm:/app .

# 使用grep查找函数调用$ grep sqrt -r app/

#找到了sqrt调用app/index.php: $x += sqrt($x);$ grep add_function -r app/

#没找到add_function调用，是PHP内置函数，sqrt 函数在 app/index.php 文件中调用了。这个文件的源码：cat app/index.php

 

sqrt 函数在 app/index.php 文件中调用了。测试sqrt循环影响了访问速度。

 

 

改正函数后，执行ab -c 10 -n 10000 http://10.240.0.5:10000/...

现在每秒的平均请求数，已经从原来的 11.85变成了 2814的正常访问速率。

解决方法:找到影响cpu占用大的进程和相应的函数，调整测试代码。