服务器性能优化提升指南(服务器性能优化提升指南下载)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

服务器性能优化提升指南

什么是性能？

性能最通俗的衡量指标就是“时间”。CPU的使用率指的是CPU用于计算的时间占比。磁盘使用率指的是磁盘操作的时间占比。当CPU使用率100%时。意味着有部分请求来不及计算。响应时间增加或者超时；当磁盘使用率100%时。意味着有部分请求需要等待IO操作。响应时间也会增加或者超时。换言之。所有的操作都在理想的时间内。就不存在“性能优化“的问题。我们在分析性能的时候。总是会首先要找到是什么引起响应时间变慢了。对应单机性能的分析。一般我们会将目光锁定在CPU和IO上。因为对于应用程序一般分为CPU bound型和IO bound型。即计算密集型或者读写密集型；至于内存。其性能因素往往也会反映到CPU或者IO上。因为内存的设计初衷就是提高内核指令和应用程序的读写性能。当内存不足。系统可能进行大量的交换操作。这时候磁盘可能成为瓶颈；而缺页。内存分配。释放。复制。内存地址空间映射等等问题又可能引起CPU的瓶颈；更严重的情况是直接影响功能。这个就不仅仅是性能的问题了。性能优化并不是一个孤立的课题。除了响应时间的考虑。我们往往还需要综合功能完整性。安全性等等方面的问题。

性能分析的基础性能优化需要厚实的基础知识：操作系统——操作系统管理着应用程序所需要的所有资源。例如CPU和IO。当任何一个组件出现问题。我们的分析也是基于操作系统的。例如文件系统类型。磁盘类型。磁盘raid类型都需要操作系统管理和支持。系统编程技术——系统编程技术涉及到我们如何使用系统资源。例如对IO的操作我们可以使用buffering I/O。也可以使用Direct IO。可以采用同步的方式。也可以采用异步的方式。可以使用多进程。也可以使用多线程的方式。懂得不同编程技术的原理。有利于问题的分析。应用程序——例如数据库组件的数据类型。引擎。索引。复制。配置参数。备份。高可用等等都可能是性能问题的元凶。

性能分析的方法论

问题分析方面。各类方法论如金字塔思维。5W2H。麦肯锡七步法等等。套用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（当然。这不是为什么性能压不满的原因）。