性能之巅：定位和优化程序CPU、内存、IO瓶颈

摘要：性能优化指在不影响系统运行正确性的前提下，使之运行得更快，完成特定功能所需的时间更短，或拥有更强大的服务能力。

1、思惟导图

---

2、什么是性能优化？

---

性能优化指在不影响系统运行正确性的前提下，使之运行得更快，完成特定功能所需的时间更短，或拥有更强大的服务能力。

关注

不一样程序有不一样的性能关注点，好比科学计算关注运算速度，游戏引擎注重渲染效率，而服务程序追求吞吐能力。

服务器通常都是可水平扩展的分布式系统，系统处理能力取决于单机负载能力和水平扩展能力，因此，提高单机性能和提高水平扩展能力是两个主要方向，理论上系统水平方向能够无限扩展，但水平扩展后每每致使通讯成本飙升（甚至瓶颈），同时面临单机处理能力降低的问题。

指标

衡量单机性能有不少指标，好比：QPS（Query Per Second）、TPS、OPS、IOPS、最大链接数、并发数等评估吞吐的指标。

CPU为了提升吞吐，会把指令执行分为多个阶段，会搞指令Pipeline，一样，软件系统为了提高处理能力，每每会引入批处理（攒包），跟CPU流水线会引发指令执行Latency增长同样，伴随着系统负载增长也会致使延迟（Latency）增长，可见，系统吞吐和延迟是两个冲突的目标。

显然，太高的延迟是不能接受的，因此，服务器性能优化的目标每每变成：追求可容忍延迟（Latency）下的最大吞吐（Throughput）。

延迟（也叫响应时间：RT）不是固定的，一般在一个范围内波动，咱们能够用平均时延去评估系统性能，但有时候，平均时延是不够的，这很容易理解，好比80%的请求都在10毫秒之内获得响应，但20%的请求时延超过2秒，而这20%的高延迟可能会引起投诉，一样不可接受。

一个改进措施是使用TP90、TP99之类的指标，它不是取平均，而是需确保排序后90%、99%请求知足时延的要求。

一般，执行效率（CPU）是咱们的重点关注，但有时候，咱们也须要关注内存占用、网络带宽、磁盘IO等，影响性能的因素不少，它是一个复杂而有趣的问题。

3、基础知识

---

能编写运行正确的程序不必定能作性能优化，性能优化有更高的要求，这样讲并非想要吓阻想作性能优化的工程师，而是实事求是讲，性能优化既须要扎实的系统知识，又须要丰富的实践经验，只有这样，你才能具有case by case分析问题解决问题的能力。

因此，相比直接给出结论，我更愿意多花些篇幅讲一些基础知识，我坚持认为底层基础是理解并掌握性能优化技能的前提，值得花费一些时间研究并掌握这些根技术。

CPU架构

你须要了解CPU架构，理解运算单元、记忆单元、控制单元是如何既各司其职又相互配合完成工做的。

• 你须要了解CPU如何读取数据，CPU如何执行任务。
• 你须要了解数据总线，地址总线和控制总线的区别和做用。
• 你须要了解指令周期：取指、译指、执行、写回。
• 你须要了解CPU Pipeline，超标量流水线，乱序执行。
• 你须要了解多CPU、多核心、逻辑核、超线程、多线程、协程这些概念。

存储金字塔

CPU的速度和访存速度相差200倍，高速缓存是跨越这个鸿沟的桥梁，你须要理解存储金字塔，而这个层次结构思惟基于着一个称为局部性原理（principle of locality）的思想，它对软硬件系统的设计和性能有着极大的影响。

局部性又分为时间局部性和空间局部性。

缓存

现代计算机系统通常有L1-L2-L3三级缓存。

好比在个人系统，我经过进入 /sys/devices/system/cpu/cpu0/cache/index0 1 2 3目录下查看。

size对应大小、type对应类型、coherency_line_size对应cache line大小。

每一个CPU核心有独立的L一、L2高速缓存，因此L1和L2是on-chip缓存；L3是多个CPU核心共享的，它是off-chip缓存。

• L1缓存又分为i-cache（指令缓存）和d-cache（数据缓存），L1缓存一般只有32K/64KB，速度高达4 cycles。
• L2缓存能到256KB，速度在8 cycles左右。
• L3则高达30MB，速度32 cycles左右。
• 而内存高达数G，访存时延则在200 cycles左右。

因此CPU->寄存器->L1->L2->L3->内存->磁盘构成存储层级结构：越靠近CPU，存储容量越小、速度越快、单位成本越高，越远离CPU，存储容量越大、速度越慢、单位成本越低。

虚拟存储器（VM）

进程和虚拟地址空间是操做系统的2个核心抽象。

系统中的全部进程共享CPU和主存资源，虚拟存储是对主存的抽象，它为每一个进程提供一个大的、一致的、私有的地址空间，咱们gdb调试的时候，打印出来的变量地址是虚拟地址。

操做系统+CPU硬件（MMU）紧密合做完成虚拟地址到物理地址的翻译（映射），这个过程老是沉默的自动的进行，不须要应用程序员的任何干预。

每一个进程有一个单独的页表（Page Table），页表是一个页表条目（PTE）的数组，该表的内容由操做系统管理，虚拟地址空间中的每一个页（4K或者8K）经过查找页表找到物理地址，页表每每是层级式的，多级页表减小了页表对存储的需求，命失（Page Fault）将致使页面调度（Swapping或者Paging），这个惩罚很重，因此，咱们要改善程序的行为，让它有更好的局部性，若是一段时间内访存的地址过于发散，将致使颠簸（Thrashing），从而严重影响程序性能。

为了加速地址翻译，MMU中增长了一个关于PTE的小的缓存，叫翻译后备缓冲器（TLB），地址翻译单元作地址翻译的时候，会先查询TLB，只有TLB命失才会查询高速缓存（L1-2-3）。

汇编基础

虽然写汇编的场景愈来愈少，但读懂汇编依然颇有必要，理解高级语言的程序是怎么转化为汇编语言有助于咱们编写高质量高性能的代码。

对于汇编，至少须要了解几种寻址模式，了解数据操做、分支、传送、控制跳转指令。

• 理解C语言的if else、while/do while/for、switch case、函数调用是怎么翻译成汇编代码。
• 理解ebp+esp寄存器在函数调用过程当中是如何构建和撤销栈帧的。
• 理解函数参数和返回值是怎么传递的。

异常和系统调用

异常会致使控制流突变，异常控制流发生在计算机系统的各个层次，异常能够分为四类：

中断（interrupt）：中断是异步发生的，来自处理器外部IO设备信号，中断处理程序分上下部。

陷阱（trap）：陷阱是有意的异常，是执行一条指令的结果，系统调用是经过陷阱实现的，陷阱在用户程序和内核之间提供一个像过程调用同样的接口：系统调用。

故障（fault）：故障由错误状况引发，它有可能被故障处理程序修复，故障发生，处理器将控制转移到故障处理程序，缺页（Page Fault）是经典的故障实例。

终止（abort）：终止是不可恢复的致命错误致使的结果，一般是硬件错误，会终止程序的执行。

系统调用：

内核态和用户态

你须要了解操做系统的一些概念，好比内核态和用户态，应用程序在用户态运行咱们编写的逻辑，一旦调用系统调用，便会经过一个特定的陷阱陷入内核，经过系统调用号标识功能，不一样于普通函数调用，陷入内核态和从内核态返回须要作上下文切换，须要作环境变量的保存和恢复工做，它会带来额外的消耗，咱们编写的程序应避免频繁作context swap，提高用户态的CPU占比是性能优化的一个目标。

进程、线程、协程

在linux内核中，进程和线程是一样的系统调用（clone），进程跟线程的区别：线程是共享存储空间的，每一个执行流有一个执行控制结构体，这里面会有一个指针，指向地址空间结构，一个进程内的多个线程，经过指向同一地址结构实现共享同一虚拟地址空间。

经过fork建立子进程的时候，不会立刻copy一份数据，而是推迟到子进程对地址空间进行改写，这样作是合理的，此即为COW（Copy On Write），在应用开发中，也有大量的相似借鉴。

协程是用户态的多执行流，C语言提供makecontext/getcontext/swapcontext系列接口，不少协程库也是基于这些接口实现的，微信的协程库libco（已开源）经过hook慢速系统调用（好比write，read）作到静默替换，很是巧妙。

连接

C/C++源代码经编译连接后产生可执行程序，其中数据和代码分段存储，咱们写的函数将进入text节，全局数据将进入数据段，未初始化的全局变量进入bss，堆和栈向着相反的方向生长，局部变量在栈里，参数经过栈传递，返回值通常经过eax寄存器返回。

想要程序运行的更快，最好把相互调用，关系紧密的函数放到代码段相近的地方，这样能提升icache命中性。减小代码量、减小函数调用、减小函数指针一样能提升i-cache命中性。

内联既避免了栈帧创建撤销的开销，又避免了控制跳转对i-cache的冲刷，因此有利于性能。一样，关键路径的性能敏感函数也应该避免递归函数。

减小函数调用（就地展开）跟封装是相违背的，有时候，为了性能，咱们不得不破坏封装和损伤可读性的代码，这是一个权衡利弊的问题。

常识和数据

CPU拷贝数据通常一秒钟能作到几百兆，固然每次拷贝的数据长度不一样，吞吐不一样。

一次函数执行若是耗费超过1000 cycles就比较大了（刨除调用子函数的开销）。

pthread_mutex_t是futex实现，不用每次都进入内核，首次加解锁大概耗时4000-5000 cycles左右，以后，每次加解锁大概120 cycles，O2优化的时候100 cycles，spinlock耗时略少。

lock内存总线+xchg须要50 cycles，一次内存屏障要50 cycles。

有一些无锁的技术，好比CAS，好比linux kernel里的kfifo，主要利用了整型回绕+内存屏障。

4、怎么作性能优化（TODO）

---

两个⽅向：提⾼运⾏速度 + 减小计算量。

性能优化监控先⾏，要基于数据⽽⾮基于猜想，要搭建能尽可能模拟真实运⾏状态的压⼒测试环境，在此基于上获取的profiling数据才是有⽤的。

方法论：监控 -> 分析 -> 优化 三部曲。

工具：

perf是linux内核自带的profiling工具，除之以外还有gprof，但gprof是侵入式的（插桩），编译的时候须要加-pg参数，会致使运行变慢（慢不少）。

perf采集的数据，能够用来生成火焰图，也能够用gprof2dot.py这个工具来产生比火焰图更直观的调用图，这些工具就是我常常用的。

gprof2dot.py连接：https://github.com/jrfonseca/gprof2dot/blob/master/gprof2dot.py

性能优化一个重要原则就是用数听说话，而不能凭空猜想。

瓶颈点可能有多个，若是不解决最狭窄的瓶颈点，性能优化就不能达到预期效果。因此性能优化以前必定要先进行性能测试，摸清家底，创建测试基线。

例子：以前作SIP协议栈，公司的产品须要提升SIP性能。美国的一个团队通过理论分析，单凭理论分析认为主要是动态内存分配是主要瓶颈，把内存申请成一大块内存，指针都变成的一大块内存的偏移量，很是难于调试，最后效果也很差。咱们又经过测试分析的方式重构了程序，性能是它们的五倍。

另外，性能优化要一个点一个点的作，作完一点，立刻作性能验证。这样能够避免无用的修改。

5、几个具体问题（TODO）

---

1. 如何定位CPU瓶颈？

CPU是一般你们最早关注的性能指标，宏观维度有核的CPU使用率，微观有函数的CPU cycle数，根据性能的模型，性能规格与CPU使用率是互相关联的，规格越高，CPU使用率越高，可是处理器的性能每每又受到内存带宽、Cache、发热等因素的影响，因此CPU使用率和规格参数之间并非简单的线性关系，因此性能规格翻倍并不能简单地翻译成咱们的CPU使用率要优化一倍。

至于CPU瓶颈的定位工具，最有名也是最有用的工具就是perf，它是性能分析的第一步，能够帮咱们找到系统的热点函数。就像人看病同样，只知道症状是不够的，须要经过医疗机器进一步分析病因，才能对症下药。

因此咱们经过性能分析工具PMU或者其余工具去进一步分析CPU热点的缘由好比是指令数自己就比较多，仍是Cache miss致使的等，这样在作性能优化的时候不会走偏。

2. 如何定位IO瓶颈？

系统IO的瓶颈能够经过CPU和负载的非线性关系体现出来。当负载增大时，系统吞吐量不能有效增大，CPU不能线性增加，其中一种多是IO出现阻塞。

系统的队列长度特别是发送、写磁盘线程的队列长度也是IO瓶颈的一个间接指标。

对于网络系统来说，我建议先从外部观察系统。所谓外部观察是指经过观察外部的网络报文交换，能够用tcpdump, wireshark等工具，抓包看一下。

好比咱们优化一个RPC项目，它的吞吐量是10TPS，客户但愿是100TPS。咱们使用wireshark抓取TCP报文流，能够分析报文之间的时间戳，响应延迟等指标来判断是不是由网络引发来的。

而后能够经过netstat -i/-s选项查看网络错误、重传等统计信息。

还能够经过iostat查看cpu等待IO的比例。

IO的概念也能够扩展到进程间通讯。

对于磁盘类的应用程序，咱们最但愿看到写磁盘有没有时延、频率如何。其中一个方法就是经过内核ftrace、perf-event事件来动态观测系统。好比记录写块设备的起始和返回时间，这样咱们就能够知道磁盘写是否有延时，也能够统计写磁盘时间耗费分布。有一个开源的工具包perf-tools里面包含着iolatency, iosnoop等工具。

3. 如何定位IO瓶颈？

应用程序经常使用的IO有两种：Disk IO和网络IO。判断系统是否存在IO瓶颈能够经过观测系统或进程的CPU的IO等待比例来进行，好比使用mpstat、top命令。

系统的队列长度特别是发送、写磁盘线程的队列长度也是IO瓶颈的一个重要指标。

对于网络 IO来说，咱们能够先使用netstat -i/-s查看网络错误、重传等统计信息，而后使用sar -n DEV 1和sar -n TCP,ETCP 1查看网路实时的统计信息。ss （Socket Statistics）工具能够提供每一个socket相关的队列、缓存等详细信息。

更直接的方法能够用tcpdump, wireshark等工具，抓包看一下。

对于Disk IO，咱们能够经过iostat -x -p xxx来查看具体设备使用率和读写平均等待时间。若是使用率接近100%，或者等待时间过长，都说明Disk IO出现饱和。

一个更细致的观察方法就是经过内核ftrace、perf-event来动态观测Linux内核。好比记录写块设备的起始和返回时间，这样咱们就能够知道磁盘写是否有延时，也能够统计写磁盘时间耗费分布。有一个开源的工具包perf-tools里面包含着iolatency, iosnoop等工具。

4.如何定位锁的问题？

你们都知道锁会引入额外开销，但锁的开销到底有多大，估计不少人没有实测过，我能够给一个数据，通常单次加解锁100 cycles，spinlock或者cas更快一点。

使用锁的时候，要注意锁的粒度，但锁的粒度也不是越小越好，太大会增长撞锁的几率，过小会致使代码更难写。

多线程场景下，若是cpu利用率上不去，而系统吞吐也上不去，那就有多是锁致使的性能降低，这个时候，能够观察程序的sys cpu和usr cpu，这个时候经过perf若是发现lock的开销大，那就没错了。

若是程序卡住了，能够用pstack把堆栈打出来，定位死锁的问题。

5. 如何提⾼Cache利用率？

内存/Cache问题是咱们常见的负载瓶颈问题，一般可利用perf等一些通用工具来辅助分析，优化cache的思想能够从两方面来着手，一个是增长局部数据/代码的连续性，提高cacheline的利用率，减小cache miss，另外一个是经过prefetch，下降miss带来的开销。

经过对数据/代码根据冷热进行重排分区，可提高cacheline的有效利用率，固然触发false-sharing另当别论，这个须要根据运行trace进行深刻调整了；

说到prefetch，用过的人每每都有一种体会，现实效果比预期差的比较远，确实不管是数据prefetch仍是代码prefetch，不肯定性太大，咱们和无线作过一些实践，最终以无线输出预取pattern，编译器自动插入prefetch的方案，效果还算能够。

剩下的，下次咱们接着说！

本文分享自华为云社区《性能之巅：定位和优化程序CPU、内存、IO瓶颈》，原文做者：左X伟。

点击关注，第一时间了解华为云新鲜技术~