《性能之巅：洞悉系统、企业与云计算》-应用程序-笔记

《性能之巅：洞悉系统、企业与云计算》第一章（绪论）和第二章（方法）的笔记，请参考Part 1，第三章（操作系统）的笔记，请参考Part 2，第四章（观测工具）的笔记，请参考Part 3，本文是第五章——应用程序。

性能调整离工作所执行的地方越近越好：最好在应用程序里。应用程序包括数据库、Web服务器、应用服务器、负载均衡器、文件服务器等。

应用程序能变得极其复杂，尤其是在涉及众多组件的分布式应用程序环境中。研究应用程序的内部通常是应用程序开发人员的领域，会涉及第三方工具自测。对于研究系统性能的人员，包括系统管理员，应用程序性能分析包括配置应用程序实现系统资源最佳利用、归纳应用程序使用系统的方式，以及常见问题的分析。

基础

对应用程序进行性能调优前，请先回答下面这些问题：

功能：应用程序的角色是什么？数据库、Web服务器、负载均衡器、文件服务器、对象存储？
操作：应用服务器服务哪些请求，或执行什么操作？数据库服务查询（和命令）、Web服务器服务HTTP请求等。这些可以用速率来度量，用以估计负载和做容量规划；
CPU模式：应用程序是用户级的软件实现还是内核级的软件实现？多数的应用程序是用户级别的，以一个或多个进程的形式执行，但是有些是以内核服务的形式实现的（例如，NFS）；
配置：应用程序是怎样配置的，为什么这么配？这些信息能在配置文件里找到或用管理工具得到。检查所有与性能相关的可调参数有没有改过，包括缓冲区大小、缓存大小、并发（进程或线程）、其他选项
指标：有没有可用的应用程序指标，如操作率？可能是用自带工具或第三方工具，通过API请求，或通过处理操作日志得到
日志：应用程序创建的操作日志是哪些？能启用什么样的日志？哪些性能指标，包括延时，能从日志中得到？例如，MySQL支持慢请求日志，对每一个慢于特定阈值的请求提供有价值的性能细节信息；
版本：应用程序是最新版本吗？在最近的版本发布说明里有没有提及性能的修复和性能的提升？
Bugs：应用程序有Bug数据库吗？你用的应用程序版本有什么样的性能Bug？如果你当前有一个性能问题，查找Bug数据库看看以前有没有发生过类似的事情，看看是怎样调查的，以及还有没有涉及其他内容。
社区/书/专家：应用程序相关的资源和文档？

目标

设立性能目标能为你的性能分析工作指明方向，并帮助你选择要做的事情。

延时：低应用程序响应时间
吞吐量：高应用程序操作率或数据传输率
资源使用率：对于给定应用程序工作负载，高效地使用资源。

常见情况的优化

一个能有效提高应用程序性能的方法是找到对应生产环境工作负载的公用代码路径，并开始对其优化。

观测性

操作系统最大的性能提升在于消除不必要的工作，应用程序也一样。

大O标记法

大O标记的示例

标记法	示例
`O(1)`	布尔判断
`O(logn)`	顺序队列的二分搜索
`O(n)`	链表的线性搜索
`O(nlogn)`	快速排序（一般情况）
`O(n^2)`	冒泡排序（一般情况）
`O(2^n)`	分解质因数、指数增长
`O(n!)`	旅行商人问题的穷举法

在这里插入图片描述

应用程序性能技术

提高应用程序性能的常用技术：选择I/O大小、缓存、缓冲区、轮询、并发和并行、非阻塞I/O、处理器绑定。

选择I/O尺寸

执行I/O的开销包括初始化缓冲区、系统调用、上下文切换、分配内核元数据、检查进程权限和限制、映射地址到设备、执行内核和驱动代码来执行I/O，以及，在最后释放元数据和缓冲区。初始化开销对于小型和大型的I/O都是差不多的。从效率上来说，每次I/O传输的数据越多，效率越高。

增加I/O尺寸是应用程序提高吞吐量的常用策略。考虑到每次I/O的固定开销，一次I/O传输128KB要比128次传输1KB高效得多。尤其是磁盘I/O，由于寻道时间，每次I/O开销都较高。

如果应用程序不需要，更大的I/O尺寸也会带来负面效应。一个执行8KB随机读取的数据库按128KB I/O的尺寸运行会慢得多，因为120KB的数据传输能力被浪费。选择小一些的I/O尺寸，更贴近应用程序所需，能降低I/O延时。不必要的大尺寸I/O还会浪费缓存空间。

缓存

缓存一致性（cache coherency）：保证完整性，确保查询不会返回过期的数据，且执行的代价不低（理想情况下，不要高于缓存所带来的益处）。

缓存提高读性能，存储通常用缓冲区来提高写性能。

缓冲区

数据在送入下一层级之前会合并放在缓冲区中，这增加I/O 大小，提升操作效率。取决于写操作类型，可能会增加写延时，第一次写入缓冲区后，在发送之前，还要等待后续写入。

环形缓冲区（或循环缓冲区）是一类用于组件之间连续数据传输的大小固定的缓冲区，缓冲区的操作是异步的。该类型缓冲可以用头指针和尾指针来实现，指针随着数据的增加或移出而改变位置。

轮询

轮询有一些潜在的性能问题：

重复检查的CPU开销高昂；
事件发生和下一次检查的延时较高。

poll()系统调用
有系统调用poll()来检查文件描述符的状态，提供与轮询相似的功能，不过它是基于事件的，因此没有轮询那样的性能负担。

poll()接口支持多个文件描述符作为一个数组，当事件发生要找到相应的文件描述符时，需要应用程序扫描这个数组。这个扫描是 $O (n)$ ，扩展时可能会变成一个性能问题。在Linux里的epoll()可避免这种扫描，复杂度是 $O (1)$ 。Solaris有一个相似的特性叫作事件端口（event ports），用port_get(3C)代替poll()。

并发和并行

分时系统（包括所有从UNIX 衍生的系统）支持程序的并发：装载和开始执行多个可运行程序的能力。虽然它们的运行时间是重叠的，但并不一定在同一瞬间都在CPU 上执行。每一个这样的程序都可以是一个应用程序进程。

多进程或多线程也是并发。

基于事件并发：event-based concurrency，应用程序服务于不同的函数并在事件发生时在这些函数之间进行切换。

并行：为了利用多处理器系统的优势，应用程序需要在同一时间运行在多颗CPU 上。

三种类型如下：

mutex（MUTually EX clusive）锁：只有锁持有者才能操作，其他线程会阻塞并等待CPU。
自旋锁：自旋锁允许锁持有者操作，其他的需要自旋锁的线程会在CPU上循环自旋，检查锁是否被释放。虽然这样可以提供低延时的访问，被阻塞的线程不会离开CPU，时刻准备着运行直到锁可用，但是线程自旋、等待也是CPU资源的浪费。
读写锁：读/写锁通过允许多个读者或只允许一个写者而没有读者，来保证数据的完整性。

非阻塞I/O

阻塞I/O两个性能问题：

对于多路并发的I/O，当阻塞时，每一个阻塞的I/O都会消耗一个线程（或进程）。为支持多路并发I/O，应用程序必须创建很多线程（通常一个客户端一个线程），伴随着线程的创建和销毁，代价也很大。
对于频繁发生的短时I/O，频繁切换上下文的开销会消耗CPU资源并增加应用程序的延时。

非阻塞I/O模型是异步地发起I/O，而不阻塞当前线程，线程可执行其他工作。

处理器绑定

NUMA环境对于进程或线程保持运行在一颗CPU上是有优势的，线程执行I/O后，能像执行I/O之前那样运行在同一CPU上。提高应用程序的内存本地性，减少内存I/O。操作系统对此是很清楚的，设计的本意就是让应用程序线程依附在同一颗CPU上（CPU亲和性，CPU affinity）。

某些应用程序会强制将自身与CPU绑定。对于某些系统，这样做能显著地提高性能。不过如果这样的绑定与其他CPU的绑定冲突，如CPU上的设备中断映射，这样的绑定就会损害性能。

云环境下，如果服务器还被其他租户的应用程序所分享并且也做绑定，那么即使其他的CPU是空闲的，也可能因为被绑定的CPU正忙于其他的租户，而发生冲突和调度器延时。

编程语言

编程语言可能是编译的或是解释的，也有可能是通过虚拟机执行的。

编译语言

编译：在运行前将程序生成机器指令，保存在二进制可执行文件里。这些文件可在任何时间运行而无须再度编译。编译语言包括C和C++。

有些语言既有解释器又有编译器。

在编译过程中，会生成一张符号表，列出程序函数和对象名称的映射地址。可使用编译器优化来提升性能，编译器优化能对CPU指令的选择和部署做优化。

gcc(1)编译器的优化区间是0～3，3 是最大数目的优化，gcc(1)能显示不同的级别用到哪些优化。命令gcc -Q -O3 --help=optimizers，完整的输出列表包括将近180项，某些即使是-O0也会启用。

选项-fomit-frame-pointer的文档：对于不需要帧指针的函数不记录帧指针。该选项避免保存、设置和恢复帧指针的指令，让函数多一个可用寄存器。还有在某些机器上启用该选项会使得调试不可能进行。

栈剖析有时很重要，一般不建议使用上面这个选项，而使用其对立面选项-fno-omit-frame-pointer。

当性能问题出现时，很容易会想用更低的优化级别（从-O3到-O2）来重新编译应用程序，寄希望于这样能满足所有的调试需求。但并不是那么简单的：编译器输出的变化可能会很大也很重要，以至于影响到你最初想要分析的那个问题的行为。

解释语言

解释语言程序的执行是将语言在运行时翻译成行为，这一过程会增加执行开销。解释语言的目标一般都不是高性能，而是易于编程和方便调试，如Shell脚本，Python。

除非提供专门的观测工具，否则对解释语言做性能分析很困难。

虚拟机

语言虚拟机（language virtual machine），或称为进程虚拟机（process virtual machine）是模拟计算机的软件。如Java和Erlang。应用程序先编译成虚拟机指令集（字节码，bytecode），再由虚拟机解释执行，解释时会把字节码转化为机器码。

虚拟机一般是语言类型里最难观测的，性能分析通常靠的是语言虚拟机提供的工具集（如DTrace探针）和三方工具。

垃圾回收

自动垃圾回收的缺点：

内存增长：针对应用程序内存使用的控制不多，当没能自动识别出对象适合被释放时内存的使用会增加。如果应用程序占用内存变得太大，达到程序的极限或引起系统换页，会严重地损害性能；
CPU成本：GC通常会间歇地运行，还会搜索和扫描内存中的对象。这会消耗CPU资源，短期内能供给应用程序的可用的CPU资源就变少。随着应用程序使用内存增多，GC对CPU的消耗也会增加。在某些情况下，可能会出现GC不断地消耗整个CPU的现象；
延时异常值：GC执行期间应用程序的执行可能会中止，偶而出现响应高延时。取决于GC的类型，全停、增量、并发。

方法和分析

应用程序性能方法

方法	类型
线程状态分析	观测分析
CPU剖析	观测分析
系统调用分析	观测分析
IO剖析	观测分析
工作负载特征归纳	观测分析，容量分析
USE方法	观测分析
向下挖掘分析法	观测分析
锁分析	观测分析
静态性能调优	观测分析，调优

建议是按表中所列顺序尝试这些方法。

线程状态分析

线程状态分析的目的是分辨应用程序线程的时间用在什么地方，这能用来很快地解决某些问题，并给其他问题的研究指明方向。通常将应用程序的时间分成几个具有实际意义的状态。

线程两个状态：

on-CPU：执行
off-CPU：等待下一轮上CPU，或等待I/O、锁、换页、工作等。

线程的六种状态（将off-CPU情况划分更细致）：

执行：在CPU上；
可运行：等待轮到上CPU；
匿名换页：可运行，但是因等待匿名换页而受阻；
睡眠：等待包括网络、块设备和数据/文本页换入在内的I/O；
锁：等待获取同步锁（等待其他线程）；
空闲：等待工作。

上面这6个状态的选择保证最小性和有用性。当然可更细分，执行状态可分为用户态和内核态执行；休眠状态可根据休眠的目标来做划分。

通过减少这些状态中的前五项的时间，会得到性能提升，同时也会增加空闲时间。若其他情况不变，则意味着应用程序的请求延时变小，能应对更多负载。一旦确定线程在前五个状态中所花时间，可进一步研究：

执行：检查执行的是用户态时间还是内核态时间，用剖析来做CPU资源消耗分析。剖析可确定哪些代码路径消耗CPU和消耗多久，包括花费在自旋锁上的时间；
可运行：在这个状态上耗时意味着应用程序需要更多的CPU资源。检查整个系统的CPU负载，以及所有对该应用程序做的CPU限制（例如，资源控制）；
匿名换页：应用程序缺少可用的主存会引起换页和延时。检查整个系统的内存使用情况，和所有对该应用程序做的内存限制；
睡眠：分析阻塞应用程序的资源；
锁：识别锁和持有该锁的线程，确定线程持锁这么长时间的原因。原因可能是持锁线程阻塞在另一个锁上，这就需要进一步的梳理。这件事情比较高阶，通常是熟悉应用程序和其锁机制的软件开发人员要做的事。

因为应用程序要等待工作，你常常会发现睡眠状态和锁状态的时间实际上就是空闲的时间。一个应用程序工作线程可能会为了工作等待条件变量（锁状态），或是为了网络I/O（睡眠状态）。当看到大量的睡眠和锁状态时间时，记住要深入检查是否真的空闲。

Linux上：

执行时间：top(1)将执行时间汇报为%CPU；
可运行时间：内核的schedstat将信息显示在/proc/*/schedstat中；还有perf sched工具
匿名换页：用内核的延时核算（delay accouting）特性来测量。工具包括：getdelay.c、DTrace、SystemTap
睡眠：pidstat -d可判断一个进程是在执行磁盘I/O还是睡眠。pstack(1)会对线程和其用户栈做一个快照，执行pstack(1)时可能会让目标有短暂停顿，应小心使用。

Solaris上，使用prstat(1M)，示意图：
在这里插入图片描述
线程各状态所用时间：