上篇文件提到，相对性能工具(Linux Performance Tools-full)图，更为实用的「性能优化工具图谱」优势在：把具体的工具同性能指标结合了起来，同时从不同的层次去描述了性能瓶颈点的分布，实用性和可操作性更强一些。系统层的工具分为CPU、内存、磁盘（含文件系统）、网络四个部分，工具集同性能工具(Linux Performance Tools-full)图中的工具基本一致。组件层和应用层中的工具构成为：JDK 提供的一些工具 + Trace 工具 + dump 分析工具 + Profiling 工具等。这里就不具体介绍这些工具的具体用法了，我们可以使用 man 命令得到工具详尽的使用说明，除此之外，还有另外一个查询命令手册的方法：info。info 可以理解为 man 的详细版本，如果 man 的输出不太好理解，可以去参考 info 文档，命令太多，记不住也没必要记住
1、首先，虽然从系统、组件、应用两个三个角度去描述瓶颈点的分布，但在实际运行时，这三者往往是相辅相成、相互影响的。系统是为应用提供了运行时环境，性能问题的本质就是系统资源达到了使用的上限，反映在应用层，就是应用/组件的各项指标开始下降；而应用/组件的不合理使用和设计，也会加速系统资源的耗尽。因此，分析瓶颈点时，需要我们结合从不同角度分析出的结果，抽出共性，得到最终的结论。
2、其次，建议先从应用层入手，分析图中标注的高频指标，抓出最重要的、最可疑的、最有可能导致性能的点，得到初步的结论后，再去系统层进行验证。这样做的好处是：很多性能瓶颈点体现在系统层，会是多变量呈现的，譬如，应用层的垃圾回收（GC）指标出现了异常，通过 JDK 自带的工具很容易观测到，但是体现在系统层上，会发现系统当前的 CPU 利用率、内存指标都不太正常，这就给我们的分析思路带来了困扰。
3、最后，如果瓶颈点在应用层和系统层均呈现出多变量分布，建议此时使用 ZProfiler、JProfiler 等工具对应用进行 Profiling，获取应用的综合性能信息（注：Profiling 指的是在应用运行时，通过事件（Event-based）、统计抽样（Sampling Statistical）或植入附加指令（Byte-Code instrumentation）等方法，收集应用运行时的信息，来研究应用行为的动态分析方法）。譬如，可以对 CPU 进行抽样统计，结合各种符号表信息，得到一段时间内应用内的代码热点。
下面介绍在不同的分析层次，我们需要关注的核心性能指标，同时，也会介绍如何初步根据这些指标，判断系统或应用是否存在性能瓶颈点，至于瓶颈点的确认、瓶颈点的成因、调优手段，将会在下一部分展开。
一、 CPU&&线程
和 CPU 相关的指标主要有以下几个。常用的工具有 top、 ps、uptime、 vmstat、 pidstat等。
a. CPU利用率（CPU Utilization）
b. CPU 平均负载（Load Average）
c. 上下文切换次数（Context Switch）
top - 12:20:57 up 25 days, 20:49, 2 users, load average: 0.93, 0.97, 0.79 Tasks: 51 total, 1 running, 50 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.6 us, 1.8 sy, 0.0 ni, 89.1 id, 0.1 wa, 0.0 hi, 0.1 si, 7.3 st KiB Mem : 8388608 total, 476436 free, 5903224 used, 2008948 buff/cache KiB Swap: 0 total, 0 free, 0 used. 0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 119680 admin 20 0 600908 72332 5768 S 2.3 0.9 52:32.61 obproxy 65877 root 20 0 93528 4936 2328 S 1.3 0.1 449:03.61 alisentry_cli
第一行显示的内容：当前时间、系统运行时间以及正在登录用户数。load average 后的三个数字，依次表示过去 1 分钟、5 分钟、15 分钟的平均负载（Load Average）。平均负载是指单位时间内，系统处于可运行状态（正在使用 CPU 或者正在等待 CPU 的进程，R 状态）和不可中断状态（D 状态）的平均进程数，也就是平均活跃进程数，CPU 平均负载和 CPU 使用率并没有直接关系。
第三行的内容表示 CPU 利用率，每一列的含义可以使用 man 查看。CPU 使用率体现了单位时间内 CPU 使用情况的统计，以百分比的方式展示。计算方式为：CPU 利用率 = 1 - （CPU 空闲时间）/ CPU 总的时间。需要注意的是，通过性能分析工具得到的 CPU 的利用率其实是某个采样时间内的 CPU 平均值。注：top 工具显示的的 CPU 利用率是把所有 CPU 核的数值加起来的，即 8 核 CPU 的利用率最大可以到达800%（可以用 htop 等更新一些的工具代替 top）。
使用 vmstat 命令，可以查看到「上下文切换次数」这个指标，如下表所示，每隔1秒输出1组数据：
$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 504804 0 1967508 0 0 644 33377 0 1 2 2 88 0 9
上表的 cs（context switch） 就是每秒上下文切换的次数，按照不同场景，CPU 上下文切换还可以分为中断上下文切换、线程上下文切换和进程上下文切换三种，但是无论是哪一种，过多的上下文切换，都会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。vmstat 的输出中 us、sy 分别用户态和内核态的 CPU 利用率，这两个值也非常具有参考意义。
vmstat 的输只给出了系统总体的上下文切换情况，要想查看每个进程的上下文切换详情（如自愿和非自愿切换），需要使用 pidstat，该命令还可以查看某个进程用户态和内核态的 CPU 利用率。
二、CPU 相关指标异常的分析思路是什么？
1）CPU 利用率：如果我们观察某段时间系统或应用进程的 CPU利用率一直很高（单个 core 超过80%），那么就值得我们警惕了。我们可以多次使用 jstack 命令 dump 应用线程栈查看热点代码，非 Java 应用可以直接使用 perf 进行 CPU 采采样，离线分析采样数据后得到 CPU 执行热点（Java 应用需要符号表进行堆栈信息映射，不能直接使用 perf得到结果）。
2）CPU 平均负载：平均负载高于 CPU 数量 70%，意味着系统存在瓶颈点，造成负载升高的原因有很多，在这里就不展开了。需要注意的是，通过监控系统监测平均负载的变化趋势，更容易定位问题，有时候大文件的加载等，也会导致平均负载瞬时升高。如果 1 分钟/5 分钟/15 分钟的三个值相差不大，那说明系统负载很平稳，则不用关注，如果这三个值逐渐降低，说明负载在渐渐升高，需要关注整体性能。
3）CPU 上下文切换：上下文切换这个指标，并没有经验值可推荐（几十到几万都有可能），这个指标值取决于系统本身的 CPU 性能，以及当前应用工作的情况。但是，如果系统或者应用的上下文切换次数出现数量级的增长，就有很大概率说明存在性能问题，如非自愿上下切换大幅度上升，说明有太多的线程在竞争 CPU。
上面这三个指标是密切相关的，如频繁的 CPU 上下文切换，可能会导致平均负载升高。如何根据这三者之间的关系进行应用调优，将在下一部分介绍。
CPU 上的的一些异动，通常也可以从线程上观测到，但需要注意的是，线程问题并不完全和 CPU 相关。与线程相关的指标，主要有下面几个（均都可以通过 JDK 自带的 jstack 工具直接或间接得到）：
应用中的总的线程数；
应用中各个线程状态的分布；
线程锁的使用情况，如死锁、锁分布等；
三、关于线程，可关注的异常有：
1）线程总数是否过多。过多的线程，体现在 CPU 上就是导致频繁的上下文切换，同时线程过多也会消耗内存，线程总数大小和应用本身和机器配置相关；
2）线程的状态是否异常。观察 WAITING/BLOCKED 线程是否过多（线程数设置过多或锁竞争剧烈），结合应用内部锁使用的情况综合分析；
3）结合 CPU 利用率，观察是否存在大量消耗 CPU 的线程。
四、内存&&堆
和内存相关的指标主要有以下几个，常用的分析工具有：top、free、vmstat、pidstat 以及 JDK 自带的一些工具。
1. 系统内存的使用情况，包括剩余内存、已用内存、可用内存、缓存/缓冲区；
2. 进程（含 Java 进程）的虚拟内存、常驻内存、共享内存；
3. 进程的缺页异常数，包含主缺页异常和次缺页异常；
4. Swap 换入和换出的内存大小、Swap 参数配置；
5. JVM 堆的分配，JVM 启动参数；
6. JVM 堆的回收，GC 情况。
使用 free 可以查看系统内存的使用情况和 Swap 分区的使用情况，top 工具可以具体到每个进程，如我们可以用使用 top 工具查看 Java 进程的常驻内存大小（RES），这两个工具结合起来，可用覆盖大多数内存指标。下面是使用 free命令的输出：
$free -h total used free shared buff/cache available Mem: 125G 6.8G 54G 2.5M 64G 118G Swap: 2.0G 305M 1.7G
上述输出各列的具体含义在这里不在赘述，也比较容易理解。重点介绍下 swap 和 buff/cache 这两个指标。
Swap 的作用是把一个本地文件或者一块磁盘空间作为内存来使用，包括换出和换入两个过程。Swap 需要读写磁盘，所以性能不是很高，事实上，包括 ElasticSearch 、Hadoop 在内绝大部分 Java 应用都建议关掉 Swap，这是因为内存的成本一直在降低，同时这也和 JVM 的垃圾回收过程有关：JVM在 GC 的时候会遍历所有用到的堆的内存，如果这部分内存被 Swap 出去了，遍历的时候就会有磁盘 I/O 产生。Swap 分区的升高一般和磁盘的使用强相关，具体分析时，需要结合缓存使用情况、swappiness 阈值以及匿名页和文件页的活跃情况综合分析。
buff/cache 是缓存和缓冲区的大小。缓存（cache）：是从磁盘读取的文件的或者向磁盘写文件时的临时存储数据，面向文件。使用 cachestat 可以查看整个系统缓存的读写命中情况，使用 cachetop 可以观察每个进程缓存的读写命中情况。缓冲区（buffer）是写入磁盘数据或从磁盘直接读取的数据的临时存储，面向块设备。free 命令的输出中，这两个指标是加在一起的，使用 vmstat 命令可以区分缓存和缓冲区，还可以看到 Swap 分区换入和换出的内存大小。
本文中提到的线程、堆、垃圾回收等名词，如无特别说明，指的是 Java 应用中的相关概念。