服务器性能优化提升指南

优化提升服务器性能指南

性能是什么？

时间是衡量性能最流行的指标，CPU利用率是指CPU磁盘利用率是指磁盘操作的时间比CPU当利用率为100%时，意味着有些请求没有时间计算，响应时间增加或加时；当磁盘利用率为100%时，意味着有些请求需要等待IO操作时，响应时间也会增加或加班。换句话说，所有的操作都在理想的时间内，没有性能优化的问题。当我们分析性能时，我们总是首先要找出是什么导致响应时间减慢。一般来说，我们会关注相应的单一性能分析CPU和IO因为应用程序一般分为CPU bound型和IO bound类型，即计算密集型或读写密集型；至于内存，往往会反映其性能因素CPU或者IO此外，由于内存设计的初衷是提高核心指令和应用程序的读写性能，当内存不足时，系统可能会进行大量的交换操作，磁盘可能成为瓶颈；可能会导致缺页、内存分配、释放、复制、内存地址空间映射等问题CPU瓶颈；更严重的情况是直接影响功能，这不仅仅是性能问题。性能优化不是一个孤立的话题。除了考虑响应时间外，我们还经常需要综合的功能完整性、安全性等问题。

性能分析的基本性能优化需要深刻的基础知识：操作系统-操作系统管理应用程序所需的所有资源，例如CPU和IO，当任何组件出现问题时，我们的分析也是基于操作系统，如文件系统类型、磁盘类型、磁盘类型raid所有类型都需要操作系统的管理和支持。系统编程技术-系统编程技术涉及到如何使用系统资源，如正确IO我们可以使用的操作buffering I/O，也可以使用Direct IO，可采用同步、异步、多过程或多线程。了解不同编程技术的原理有利于问题的分析。数据类型、引擎、索引、复制、配置参数、备份、高可用性等应用程序可能是性能问题的罪魁祸首。

性能分析方法论

在问题分析方面，金字塔思维、5等各种方法W2H、麦肯锡七步法等。应用5W2H性能分析可以提出几个问题

What-现象的表现是什么？

When-何时发生

Why-为什么会发生？

Where-问题发生在哪里？

How much-消耗了多少资源，解决问题后能减少多少资源消耗

How to do-如何解决问题

但这些只能给出方向，性能分析需要找到更具体的方法来解决问题。Brendan Gregg在《性能之巅:洞察系统、企业与云计算》第二章中，有很多突出的方法Use方法、负载特征归纳、性能监控、静态性能优化、延迟分析、工具法等。其中，工具法是最具体的，但工具法也有自己的限制，如磁盘的饱和度。当磁盘利用率为100%时，磁盘的负载可能会继续增加。在实际分析中，负载特征归纳更具指导意义。静态跟踪和动态跟踪使我们更容易更直观地发现问题。CPU认识

CPU：CPU这里不详细介绍自己的架构和核心调度器的架构构了。详情请参考操作系统书籍。但还是需要明确一些概念:

.处理器

.核

.硬件线程

.CPU内存缓存

.时钟频率

.每个指令周期数CPI每个周期的指令数IPC

.CPU指令

.使用率

.用户时间/内核时间

.调度器

.运行队列

.抢占

.多进程

.多线程

.字长

对于应用程序，我们通常关注核心CPU调度器的功能和性能

线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类一般分为：on-CPU：在执行间通常分为用户态时间user和系统态时间sysoff-CPU：等待下一轮CPU，或者等待I/O、锁、换页等，其状态可细分为可执行、匿名换页、睡眠、锁、空闲等CPU上，对CPU如果系统时间大，分析可以快速解释原因；off-cpu状态，定位问题会花很多时间。

分析方法和工具在观察CPU性能时，可根据负载特性进行总结，检查以下清单：

在整个系统范围内CPU负载如何，CPU使用率如何，单个CPU利用率呢？

CPU负载并发程度如何？是单线程吗？有多少线程？

使用哪个应用程序CPU，用了多少？

使用哪个内核线程？CPU，用了多少？

中断的CPU用量是多少？

使用用户空间和核心空间CPU调用路径是什么？

什么样的停滞周期？

回答上述问题，使用系统性能分析工具是最经济、最直接的，这里列出的工具足以回答上述问题：

调用路径和停滞周期的分析可用于上述问题perf也可以使用工具DTrace等待更灵活的工具perf可用于支持各种核心时间的跟踪计数统计perf list查看。例如，停滞周期分析可能非常复杂，需要正确CPU对调度器结构有更系统的理解和理解，停滞周期可能发生在一级、二级或三级缓存，如未命中缓存或内存IO和资源IO停滞周期，perf中有诸如L1-dcahce-loads，L1-icache-loads等待事件的计数统计。

实际案例火焰图有助于分析CPU我们正在测量调用路径mysql分析了某个模型的非原地更新性能mysql分析了服务器延迟的情况CPU主要函数调用perf top可以看到调用次数的排名，但调用关系无法显示。火焰图清楚地提供了调用关系的视图(以下两张图片中的比例不同是因为perf top加了-p火焰图分析是针对整个系统的参数)。

内存：

正如前面所述，内存是为了提高效率而产生的。在实际分析问题时，内存问题不仅会影响性能，还会影响服务或其他问题。内存的一些概念也需要明确：

主存

虚拟内存

常驻内存

地址空间

OOM

页缓存

ȱҳ

换页

交换空间

交换

用户分配器libc、glibc、libmalloc和mtmalloc

LINUX内核级SLUB分配器

分析方法和工具Brendan书中有一些问题，比如内存总线的平衡，NUMA在实际分析问题时，这些问题不能作为切入点，需要持续分析。因此，作者将其简化为以下列表：

物理内存和虚拟内存在系统范围内的利用率

换页、交换，oom的情况

使用内核和文件系统缓存

内存在哪里？

为什么过程分配内存？

内核为何分配内存

持续交换哪些过程

过程或内存是否有内存泄漏？

内存分析工具如下

除了DTrace，所有工具只能回答信息统计、过程中的内存使用等。至于是否有内存泄漏，只能通过分配跟踪DTrace通过对内核函数有深入的了解D语言编写脚本完成跟踪。Perf还有一些，比如cache-miss、page-faults跟踪事件，但不直观。

在实际情况下，很难从监控和顶层观察中发现内存泄漏的问题。一般来说，它是从底层程序代码进行分析的。各种观察工具和跟踪工具的使用不能确定原因，只能通过分析代码来调查问题。最终的发现是lua在包驱动的周期性服务用法中，脚本语言分配内存速度快，包驱动，lua自动回收不能快速释放内存，而是集中回收。如果经常回收，可能会带来CPU的压力。开发项目组最后采用的解决方式为分步回收，每次回收一部分内存，然后周期性全量回收。

IO

逻辑IO vs 物理IO通常在讨论问题时，总是分析IO的负载，IO负载通常指磁盘IO，也就是物理IO，例如，我们使用它iostat获取的avgqu-sz、svctm和until等待指标。因为我们的读写最终来自或去磁盘，关注磁盘IO情况非常正确。但而，当我们进行读写操作时，除非使用，否则面向文件系统的对象不会直接面向磁盘raw io的方式。

下图是通用的IO如果想了解更多，可以查看第二张图片。我们知道LINUX所有硬件设备甚至网络都通过文件系统抽象成文件管理read()调用时，其实就是调用vfs_read函数、文件系统将确认请求的数据是否在页面缓存中，如果不在内存中，请求将发送到块设备；此时，核心将首先获得物理设备上数据的实际位置，然后将读取请求发送到块设备的请求队列，IO调度器将通过一定的调度算法将请求发送到磁盘设备的驱动层，以执行真正的读取操作。在这个过程中可能会发生什么？如果应用程序执行大量的顺序读取会发生什么？随机阅读会发生什么？如果是顺序读取，正确的方法是预读，使请求数据落入内存，提高读取效率。因此，在应用程序开始读取时，从文件系统到磁盘，存在读取放大的问题。

在写作操作中也有类似的情况，应用程序启动文件系统IO操作，物理IO有时与应用程序无关、间接、放大或缩小。

无关:其他应用:磁盘IO监控，agent其他用户：如虚拟机母机下其他用户的其他核心任务：如重建raid，校验等

间接:文件系统预读:增加额外的IO，但预读数据无用文件系统缓冲：写缓存延迟或合并回写磁盘，导致磁盘瞬时IO压力

放大：文件系统元数据：增加额外数据IO文件系统记录尺寸：向上对齐等IO大小

缩小：文件系统缓存：直接读取缓存，无需操作磁盘合并：一次性重写磁盘文件系统抵消：同一地址多次更新，重写磁盘次修改压缩：减少数据量

文件系统

与工具和文件系统相关的分析术语如下：

文件系统

VFS

缓存文件系统

页缓存page cache

高速缓存缓冲区buffer cache

目录缓存

inode

inode缓存

下图显示了文件系统缓存的结构图，页面缓存了虚拟内存的页面，包括文件系统的页面，提高了文件和目录的性能。

Linux将缓冲区的高速缓存放入页面缓存中page cache包含buffer cache。文件系统中使用的内存脏页由内核线程写回磁盘，如图所示kswapd更换后台页面的过程，当内存不足时，超过一定时间(30s）或者当有太多的脏页触发磁盘回写。

文件系统延迟是指从开始到结束的时间，包括文件系统和内核磁盘IO子系统和等待磁盘设备响应的时间。当同步访问时，应用程序将被阻塞，等待文件系统请求结束。在异步模式下，文件系统对其没有直接影响，但也分为异步访问select、poll、epoll等方式，也就是所谓的异步阻塞、异步非阻塞。在异步方式下，一般打印用户层发起的文件系统逻辑IO哪个函数产生了调用栈IO。Linux未提供查看文件系统延迟的工具和接口，但磁盘的指标信息相对丰富，但在许多情况下，文件系统IO和磁盘IO它们之间没有直接的关系，比如应用程序写文件系统，但不在乎数据什么时候写到磁盘，当后台刷数据到磁盘时，可能会导致磁盘IO从磁盘的角度来看，应用程序的写入可能会受到影响，但实际上应用程序并没有等待。

文件系统的分析可以尝试回答以下问题：哪个应用程序正在使用文件系统？操作哪些文件？在什么样的操作中，读写比是多少，同步还是异步？文件系统的缓存是多少，目前的使用情况是什么？有什么错误吗？请求是非法的，还是文件系统本身的问题？事实上，上述问题，除了可以看到系统的内存、页面缓存和buffer cache大小，可以看到读写操作中的哪些过程，读取哪些文件，其他问题，如应用程序对文件系统的读写比、同步或异步，没有工具可以给出明确的信息。当然，我们可以跟踪应用程序的核心调用堆栈，或者在应用程序中输出日志来帮助分析问题。

磁盘分析

用工具理解磁盘IO之前，同样我们需要理解一些概念，例如：

虚拟磁盘

扇区

I/O请求

磁盘命令

带宽

吞吐

I/O延时

服务时间

等待时间

随机IO/连续IO

同步/异步

磁盘接口

raid

对于磁盘IO，我们可以列出以下问题来帮助我们分析性能问题：

每个磁盘的利用率是多少？

在每个磁盘上等待队列需要多长时间？

平均服务时间和等待时间是多少？

哪个应用程序或用户正在使用磁盘？

读写应用程序的方式是什么？

磁盘为何启动？IO，内核调用路径是什么？

磁盘上的读写比是多少？

随机IO还是顺序IO？

Linux磁盘的性能分析工具如下：

磁盘是随机的IO还是顺序IO，很多时候，我们没有很好的判断方法，因为当块设备重写磁盘时，它是随机的IO可能已经整理成顺序了IO对磁盘的分析也可以使用perf跟踪事件或DTrace设置探针。在分析mysql不完整的模型cache当非本地更新时，为什么当单个例子不能填充机器性能时，我们在分析过程中跟踪了设备的核心事件。我们比较了磁盘在多个例子非本地更新和单个例子非本地更新时的操作。以下是非本地更新时跟踪的结果。在分析结果后，我们可以看到，近30%的单个例子非本地更新blk_finish_plug，有70%是blk_queue_bio，而实例恰恰相反，大量blk_finish_plug和少量的blk_queue_bio(当然，这不是性能压力不满的原因)。