高楼的性能工程实战课笔记-004-性能分析决策树&证据链

如何构建性能分析决策树？
    性能分析决策树在性能监控设计和性能瓶颈分析时都会被使用，并且在性能瓶颈分析时，我们必须要有决策树的思路。
    
    什么是性能分析决策树呢？
        性能分析决策树是包括了系统架构中所有技术组件、所有组件中的模块以及模块对应计数器的完整的结构化树状图。
            组件===》模块===》计数器
            
    如何构建性能分析决策树？
        构建性能分析决策树是我们了解一个系统非常关键的环节，总体来看，它分为 4 个步骤。
        1. 第一步：根据系统的架构，罗列出整个系统架构中的组件。
        2. 第二步：深入细化组件中的每一个重要的模块。
        3. 第三步：列出模块对应的计数器。注意把每个模块重要的计数器都囊括进来，千万不能漏掉重要的第一级计数器，如果漏掉的话，有些数据可能就需要重新跑了。
        4. 画出计数器之间的相关性。
            
        最后画出相应的性能分析决策树，最终形成一张完整的大图。
        
    收集计数器的实时数据
        注意，在收集计数器的实时数据时，可能不是一个监控工具就可以完全覆盖所有的计数器的。
        在分析的时候，我们一定要清楚监控工具的局限在哪里。如果一个工具无法监控到全部的计数器，那就必须用多个工具相互补充，
        比如说对于 Linux 操作系统的监控，现在我们最常用的监控工具就是 prometheus+grafana+node_exporter
        
        在使用监控工具之前，一定要把性能分析决策树中的计数器，与监控工具中的计数器做对比，缺什么，我们就要在分析时用其他的监控工具或是命令来做补充。
        请你记住一点，用什么监控工具并不重要，有没有监控到全部的计数器才重要。不要迷信工具！
        
        【注意】，理解每个计数器的含义才是至关重要的。如果不理解计数器的含义，也不知道如何运用计数器，那我们就不可能知道怎么去做分析。    
        
        
    实例：
        【组件】操作系统===》【重要模块】===》【计数器】
        
        【模块】
            Swap 的存在是为了让系统在没有内存可用的时候，可以用硬盘来做内存的交换分区。
            当 Swap 被用到时，其实就说明性能已经有了问题。所以，一般不建议在性能项目中使用 Swap
            
        【计数器】--cpu模块的计数器
            top 命令中有九个计数器，分别是：us/sy/ni/id/wa/hi/si/st/load average。
            load average 是什么呢？load average 是 1m/5m/15m 内的可运行状态和不可中断状态的平均进程数。
                “可运行状态”除了tasks 中的 Running 状态的任务还包括一些万事俱备只差 CPU 的情况。
                也就是说 tasks 中的 Running 状态的任务数，与 load average 的值之间并不是直接的等价关系。
            在 vmstat 的 proc 列有两个参数：r  和  b。
                r: The number of runnable processes (running or waiting for run time).
                b: The number of processes in uninterruptible sleep.
            其中，r  是指正在运行状态和等待运行状态的进程
            对于不可中断状态，我们经常见到的就是等 IO。当然，也不止是等 IO，内存交换也会在这个状态里，这种等 IO 的情况会体现在 vmstat 中 proc 下面的 b 列。
            
            【load average 实际上就是 vmstat 中 proc 列的 r 与 b 之和。】
            
            ~]# mpstat -P ALL 2
            %guest Show the percentage of time spent by the CPU or CPUs to run a virtual processor.
            %gnice Show the percentage of time spent by the CPU or CPUs to run a niced guest.
            
            %guest 和 %gnice 这两个参数，是比较有意义的，说明 Guest 虚拟机消耗 CPU 的比例。
            如果宿主机上有多个虚拟机，你就可以通过这两个参数值来看虚拟机是不是消耗 CPU 太多，然后通过查进程的方式看看具体是哪一个虚拟机消耗得多。
            
            在 Linux 操作系统中，如果是宿主机，我们就需要看 11 个计数器。如果是虚拟机的话，看 9 个计数器（图中前 9 个）就可以了
            
怎么查找性能瓶颈证据链？
    性能分析中有一个非常关键的词，那就是“证据链”。
    如果性能分析没有证据链，那么分析思路就是跳跃的。通俗点讲，就是蒙，根据经验蒙，根据资料蒙。这种跳跃的分析思路是非常容易出错的。
    我们在分析性能瓶颈时，一定要有理有据、顺藤摸瓜。

 

 

 

    【实例】
        全局监控分析===》某个CPU的%us 使用率并没有很高，%id 也不小，还有一些剩余。但是 %si（软中断）这一项，唯独第 22 颗 CPU 的 %si 有 21.4% 之高。===》
        性能分析决策树中 CPU 监控的具体命令。所以我们接下来的分析逻辑就是：根据性能瓶颈的分析应用，选择相应的监控手段，覆盖性能分析决策树中需要监控的计数器，然后再进一步细化分析。===》
        定向监控===》/proc/softirqs
        由于/proc/softirqs 文件中的各个计数器都是累加值，其他模块在各个 CPU 上的累加值比例都没有太大的差别，只有 NET_RX 模块在不同 CPU 上的计数值差别很大。所以，我们可以作出这样的判断：CPU 22 的使用率高是因为 NET_RX【网络接收数据】。
        
        网络的接收是靠队列来缓存数据的=========》
        检查网络接收的队列有多少个  =========》
            通过 /sys/class/net/< 网卡名 >/queues/ 路径，查看到这个网络队列只有一个
        增加网络接收队列
        
        【注意】
        我们一开始并不会直接去看 cat/proc/softirqs 的内容，因为这个太定向、太具体了。
        我们一定要先看全局的数据，然后再一步一步往下去找，这样才是合理的。
        不难发现，我们从全局监控分析拿到的数据，和从定向监控分析拿到的数据是不一样的，因为它们是不同的角度，这一点你也要格外注意。