目录
 
内存性能指标
 
内存性能工具
 
如何快速分析内存的性能指标
 

 
 
内存性能指标
 
系统内存使用情况
 1.已用内存和剩余内存
 2.共享内存，通过tmpfs实现的，他的大小就是tmpfs使用的内存大小，这是一个特殊的缓存
 3.可用内存是新进程可以使用的最大内存，包括剩余内存和可回收缓存
 4.缓存包括，从磁盘读取文件页的buffer缓存，用来缓存从磁盘读取的数据加速再次访问
    还包括Slab分歧中的可回收内存
 5.缓冲区是对原始磁盘块的临时存储，用来缓存将要写入磁盘的数据，内核可以把分散的写集中起来，统一
    优化磁盘写入
 
进程内存使用情况
 如进程的虚拟内存，常驻内存，共享内存，swap内存等
 1.虚拟内存，包括了进程代码段，数据段，共享内存，已经申请的堆内存和已经换出的内存等，注意，已经
   申请的内存，即使还没有分配物理内存，也算作虚拟内存
 2.常驻内存是进程实际使用的物理内存，不包括swap和共享内存，一般会换算成占系统总内存的百分比，
    也就是进程的内存使用率
 3.共享内存，包括与其他进程共同使用的真是的共享内存，还包括了加载的动态链接库以及程序代码段等
 4.Swap内存，是指通过Swap换出到磁盘的内存
 
缺页异常
 系统调用内存分配请求后，并不会立刻为其分配物理内存，而是在首次访问时，通过缺页异常来分配，缺页
   异常包括两类
 1.可以直接从物理内存中分配时，称为次缺页异常
 2.需要磁盘I/O介入，比如Swap时，被成为主缺页异常，主缺页异常升高，意味着需要磁盘I/O，会导致
    内存访问变慢很多
 
Swap的使用情况
 如swap的已用空间，剩余空间，换入速度和换出速度等
 1.已用空间和剩余空间很好理解，就是字面上的意思，已使用和没有使用的内存空间
 2.换入和换出速度，则表示每秒钟换入和换出内存的大小
  
 
内存的性能指标相关的思维导图
 
 
 
 

内存性能工具
 
比如free 查看整体内存和swap情况
 top和ps 查看进程的内存情况
 在proc中还有很多内存指标的来源，如/proc/zoneinfo等
 通过vmstat可以动态观察内存变化情况
 通过cachestat 查看整个系统缓存的读写命中情况
 通过cachetop来观察每个进程缓存的读写命中情况
 memleak查看内存分配，找到内存泄露的位置
 通过sar也可以实时的查看内存使用情况
  
 
性能指标和工具联系
 同CPU一样，可以从两个不同维度出发
 1.从内存指标出发，把工具和工作原理关联起来
 2.从性能工具出发，可以更快的利用工具，找出我们想观察的性能指标，特别是工具有限的情况下，得充分
    利用手头的每一个工具，挖掘更多问题
 
根据指标找工具
 
 
从性能工具出发，最大化利用已有的工具，找到想要的指标
 根据工具查找指标(内存性能)
 
 
 
 

如何快速分析内存的性能指标
 
在实际环境中，我们希望尽可能快的定位系统瓶颈，然后尽可能快的优化性能，就是要又快又准的性能相关的问题
 虽然内存性能指标很多，但都是魏了描述内存的原理，指标间自然不会完全孤立，一般都会有关联，反过来说，这些关联也正是源于系统的内存原理
 为了快速定位内存问题，可以先运行几个覆盖面比较大的性能工具，如free，top，vmstat，pidstat等
 具体粉丝思路如下
 1.先用free和top，查看系统整体的内存使用情况
 2.再用vmstat和pidstat，查看一段时间的趋势，从而判断出内存的问题类型
 3.最后进行详细分析，比如内存分配分析，缓存/缓冲区分析，具体进程的内存使用分析等
 
相关流程图如下
 
 
几个例子
 1.当通过free发现大部分内存都会缓存占用后，就可以使用vmstat或者sar观察缓存变化趋势，确认缓存的
   使用是否还在继续增大，如果继续增大，说明导致缓存升高的进程还在运行，再用cachestat和cachetop
   分析这些缓存到底被哪里占用
 2.用free发现可用内存不足，首先要确认内存是否被缓存/缓冲区占用，排除缓存/缓冲区后，可以继续用
    pidstat或top，定位占用内存最多的进程，找出进程后，再通过进程内存空间工具(如pmap)分析
    进程地址空间中内存的使用情况
 3.当通过vmstat或sar发现内存不断增长，可以分析是否存在内存泄露问题，使用memleak检查是否存在
    内存泄露，memleak输出内存泄露的进程以及调用堆栈
 
 
 

 虽然内存的性能指标和性能工具都很多，但理解其原理后，会发现他们之间有一定关联
 找到内存问题来源后，下一步就是相应的优化工作了，内存调优最重要的是，保证应用程序的热点数据放到内存中，并尽量减少换页和交换
 常见的优化思路如下
 1.最好禁止Swap，如必须开启Swap，降低swappiness的值，减少内存回收时Swap的使用倾向
 2.减少内存的动态分配，比如可以使用内存池，大页(HugePage)等
 3.尽量使用缓存和缓冲区来访问数据，比如可以使用堆栈明确声明内存空间，来存储需要缓存的数据，或
   用Redis这类的外部缓存组建，优化数据的访问
 4.使用cgroups等方式限制进程的内存使用情况，这样可以确保系统内存不会被异常进程耗尽
 5.通过/proc/[PID]/oom_adj，调整核心应用的oom_score，可以保证及时内存紧张，核心应用也不会被OOM
   杀死
  
 
 
 
 

1.场景还原
 
    在实际的开发维护工作中，mysql优化是一个不可绕道的优化方案，今天笔者就笼统的列出优化的几点思路
 
2.优化思路
 
①表结构的合理化设计，前提必须满足3NF；
 
②添加适当的索引，索引大体分为四种：主键索引，唯一索引，全文索引，普通索引
 
③分表技术（水平分割，垂直分割）
 
④读写分离（主写从读）
 
⑤存储过程（模块化编程，可提高速度）
 
⑥mysql配置优化（配置最大并发数，调整缓存大小）
 
⑦定时清理不需要的数据，定时进行碎片整理
 
⑧对mysql服务器硬件升级（cpu 内存等）
 
仅提供以上优化思路，具体可行措施见笔者后续博文
 
好了，我是张星，欢迎加入博主技术交流群，群号：526601468

目录
 
确定优化目标
 
网络性能工具
 
网络性能优化
 
应用程序
 
套接字
 
传输层
 
网络层
 
链路层
 


确定优化目标
 
优化前，首先要确定观察到的网络性能指标，要达到多少才合适？
 虽然网络性能优化的整体目标，是降低网络延迟（如 RTT）和提高吞吐量（如 BPS 和 PPS），但具体到不同应用中，每个指标的优化标准可能会不同，优先级顺序也大相径庭。
 
NAT 网关通常需要达到或接近线性转发，也就是说， PPS 是最主要的性能目标。
对于数据库、缓存等系统，快速完成网络收发，即低延迟，是主要的性能目标。
而对于我们经常访问的 Web 服务来说，则需要同时兼顾吞吐量和延迟。
为了更客观合理地评估优化效果，我们首先应该明确优化的标准，即要对系统和应用程序进行基准测试，得到网络协议栈各层的基准性能。
 Linux 网络协议栈，是我们需要掌握的核心原理。它是基于 TCP/IP 协议族的分层结构，用一张图来表示这个结构。
 
 

 由于底层是其上方各层的基础，底层性能也就决定了高层性能。底层性能指标就是对应高层的极限性能。
 
首先是网络接口层和网络层，它们主要负责网络包的封装、寻址、路由，以及发送和接收。每秒可处理的网络包数 PPS，就是它们最重要的性能指标（特别是在小包的情况下）。可以用内核自带的发包工具 pktgen ，来测试 PPS 的性能。
再向上到传输层的 TCP 和 UDP，它们主要负责网络传输。对它们而言，吞吐量（BPS）、连接数以及延迟，就是最重要的性能指标。可以用 iperf 或 netperf ，来测试传输层的性能。不过要注意，网络包的大小，会直接影响这些指标的值。所以需要测试一系列不同大小网络包的性能。
最后，再往上到了应用层，最需要关注的是吞吐量（BPS）、每秒请求数以及延迟等指标。可以用 wrk、ab 等工具，来测试应用程序的性能。
测试场景要尽量模拟生产环境，这样的测试才更有价值。可以到生产环境中，录制实际的请求情况，再到测试中回放。
 
 
 
网络性能工具
 
建议从指标和工具两个不同维度出发，整理记忆网络相关的性能工具。
 第一个维度，从网络性能指标出发，把性能工具同系统工作原理关联起来，对性能问题有宏观的认识和把握。当想查看某个性能指标时，就能清楚知道，可以用哪些工具。
 
下图可以把它当成一个“指标工具”指南来使用
 
 
再来看第二个维度，从性能工具出发。可以更快上手使用工具，迅速找出想要观察的性能指标。特别是在工具有限的情况下，要充分利用好手头的每一个工具，用少量工具也要尽力挖掘出大量信息。
 下图可以当成一个“工具指标”指南使用，需要时查表即可
 
 
 
 
网络性能优化
 
总的来说，先要获得网络基准测试报告，然后通过相关性能工具，定位出网络性能瓶颈。再接下来的优化工作，就是水到渠成的事情了。
 要优化网络性能，肯定离不开 Linux 系统的网络协议栈和网络收发流程的辅助。可以结合下面这张图再回忆一下这部分的知识
 
 
可以从应用程序、套接字、传输层、网络层以及链路层等几个角度，分别来看网络性能优化的基本思路。
 
应用程序
 
应用程序，通常通过套接字接口进行网络操作。由于网络收发通常比较耗时，所以应用程序的优化，主要就是对网络 I/O 和进程自身的工作模型的优化。
 
相关内容，参考 C10K 和 C1000K 
 
从网络 I/O 的角度来说，主要有下面两种优化思路
 
第一种是最常用的 I/O 多路复用技术 epoll，主要用来取代 select 和 poll。这其实是解决 C10K 问题的关键，也是目前很多网络应用默认使用的机制。
 
第二种是使用异步 I/O（Asynchronous I/O，AIO）。AIO 允许应用程序同时发起很多 I/O 操作，而不用等待这些操作完成。等到 I/O 完成后，系统会用事件通知的方式，告诉应用程序结果。不过，AIO 的使用比较复杂，你需要小心处理很多边缘情况。
 
而从进程的工作模型来说，也有两种不同的模型用来优化。
 
第一种，主进程 + 多个 worker 子进程。其中，主进程负责管理网络连接，而子进程负责实际的业务处理。这也是最常用的一种模型。
 
第二种，监听到相同端口的多进程模型。在这种模型下，所有进程都会监听相同接口，并且开启 SO_REUSEPORT 选项，由内核负责，把请求负载均衡到这些监听进程中去。
 
除了网络 I/O 和进程的工作模型外，应用层的网络协议优化，也是至关重要的一点。我总结了常见的几种优化方法。
 
使用长连接取代短连接，可以显著降低 TCP 建立连接的成本。在每秒请求次数较多时，这样做的效果非常明显。
使用内存等方式，来缓存不常变化的数据，可以降低网络 I/O 次数，同时加快应用程序的响应速度。
使用 Protocol Buffer 等序列化的方式，压缩网络 I/O 的数据量，可以提高应用程序的吞吐。
使用 DNS 缓存、预取、HTTPDNS 等方式，减少 DNS 解析的延迟，也可以提升网络 I/O 的整体速度。
 
 
套接字
 
套接字可以屏蔽掉 Linux 内核中不同协议的差异，为应用程序提供统一的访问接口。每个套接字，都有一个读写缓冲区。
 
读缓冲区，缓存了远端发过来的数据。如果读缓冲区已满，就不能再接收新的数据。
写缓冲区，缓存了要发出去的数据。如果写缓冲区已满，应用程序的写操作就会被阻塞。
所以，为了提高网络的吞吐量，通常需要调整这些缓冲区的大小。比如
 
增大每个套接字的缓冲区大小 net.core.optmem_max
增大套接字接收缓冲区大小 net.core.rmem_max 和发送缓冲区大小 net.core.wmem_max
增大 TCP 接收缓冲区大小 net.ipv4.tcp_rmem 和发送缓冲区大小 net.ipv4.tcp_wmem
下图是套接字的内核选项表格
 
 
有几点需要你注意
 
tcp_rmem 和 tcp_wmem 的三个数值分别是 min，default，max，系统会根据这些设置，自动调整 TCP 接收 / 发送缓冲区的大小
udp_mem 的三个数值分别是 min，pressure，max，系统会根据这些设置，自动调整 UDP 发送缓冲区的大小
当然，表格中的数值只提供参考价值，具体应该设置多少，还需要你根据实际的网络状况来确定。比如，发送缓冲区大小，理想数值是吞吐量 * 延迟，这样才可以达到最大网络利用率。
 
除此之外，套接字接口还提供了一些配置选项，用来修改网络连接的行为。
 
为 TCP 连接设置 TCP_NODELAY 后，就可以禁用 Nagle 算法
为 TCP 连接开启 TCP_CORK 后，可以让小包聚合成大包后再发送（注意会阻塞小包的发送）
使用 SO_SNDBUF 和 SO_RCVBUF ，可以分别调整套接字发送缓冲区和接收缓冲区的大小
  
 
 
传输层
 
传输层最重要的是 TCP 和 UDP 协议，所以这儿的优化，其实主要就是对这两种协议的优化。
 
TCP 提供了面向连接的可靠传输服务。要优化 TCP，首先要掌握 TCP 协议的基本原理，比如流量控制、慢启动、拥塞避免、延迟确认以及状态流图（如下图所示）等
 
 
可以在不破坏 TCP 正常工作的基础上，对它进行优化。
 
第一类，在请求数比较大的场景下，可能会看到大量处于 TIME_WAIT 状态的连接，它们会占用大量内存和端口资源。可以优化与 TIME_WAIT 状态相关的内核选项，比如采取下面几种措施。
 
增大处于 TIME_WAIT 状态的连接数量 net.ipv4.tcp_max_tw_buckets ，并增大连接跟踪表的大小 net.netfilter.nf_conntrack_max。
减小 net.ipv4.tcp_fin_timeout 和 net.netfilter.nf_conntrack_tcp_timeout_time_wait ，让系统尽快释放它们所占用的资源。
开启端口复用 net.ipv4.tcp_tw_reuse。这样，被 TIME_WAIT 状态占用的端口，还能用到新建的连接中。
增大本地端口的范围 net.ipv4.ip_local_port_range 。这样就可以支持更多连接，提高整体的并发能力。
增加最大文件描述符的数量。你可以使用 fs.nr_open ，设置系统的最大文件描述符数；或在应用程序的 systemd 配置文件中，配置 LimitNOFILE ，设置应用程序的最大文件描述符数。
第二类，为了缓解 SYN FLOOD 等，利用 TCP 协议特点进行攻击而引发的性能问题，可以考虑优化与 SYN 状态相关的内核选项，比如采取下面几种措施。
 
增大 TCP 半连接的最大数量 net.ipv4.tcp_max_syn_backlog ，或者开启 TCP SYN Cookies net.ipv4.tcp_syncookies ，来绕开半连接数量限制的问题（注意，这两个选项不可同时使用）
减少 SYN_RECV 状态的连接重传 SYN+ACK 包的次数 net.ipv4.tcp_synack_retries
第三类，在长连接的场景中，通常使用 Keepalive 来检测 TCP 连接的状态，以便对端连接断开后，可以自动回收。但是，系统默认的 Keepalive 探测间隔和重试次数，一般都无法满足应用程序的性能要求。所以，这时候需要优化与 Keepalive 相关的内核选项，比如：
 
缩短最后一次数据包到 Keepalive 探测包的间隔时间 net.ipv4.tcp_keepalive_time；
 缩短发送 Keepalive 探测包的间隔时间 net.ipv4.tcp_keepalive_intvl；
 减少 Keepalive 探测失败后，一直到通知应用程序前的重试次数 net.ipv4.tcp_keepalive_probes。
 下图是 TCP 优化方法的表格
 
 
优化 TCP 性能时，需要注意，如果同时使用不同优化方法，可能会产生冲突。
 
比如，服务器端开启 Nagle 算法，而客户端开启延迟确认机制，就很容易导致网络延迟增大。
 另外，在使用 NAT 的服务器上，如果开启 net.ipv4.tcp_tw_recycle ，就很容易导致各种连接失败。实际上，由于坑太多，这个选项在内核的 4.1 版本中已经删除了。
 
再来看 UDP 的优化。
 
UDP 提供了面向数据报的网络协议，它不需要网络连接，也不提供可靠性保障。所以，UDP 优化，相对于 TCP 来说，要简单得多。这里我也总结了常见的几种优化方案。
 
跟上篇套接字部分提到的一样，增大套接字缓冲区大小以及 UDP 缓冲区范围。
跟前面 TCP 部分提到的一样，增大本地端口号的范围；
根据 MTU 大小，调整 UDP 数据包的大小，减少或者避免分片的发生。
 
 
网络层
 
网络层，负责网络包的封装、寻址和路由，包括 IP、ICMP 等常见协议。在网络层，最主要的优化，其实就是对路由、 IP 分片以及 ICMP 等进行调优。
 
第一种，从路由和转发的角度出发，你可以调整下面的内核选项。
 
在需要转发的服务器中，比如用作 NAT 网关的服务器或者使用 Docker 容器时，开启 IP 转发，即设置 net.ipv4.ip_forward = 1。
调整数据包的生存周期 TTL，比如设置 net.ipv4.ip_default_ttl = 64。注意，增大该值会降低系统性能。
开启数据包的反向地址校验，比如设置 net.ipv4.conf.eth0.rp_filter = 1。这样可以防止 IP 欺骗，并减少伪造 IP 带来的 DDoS 问题。
第二种，从分片的角度出发，最主要的是调整 MTU（Maximum Transmission Unit）的大小。
 通常，MTU 的大小应该根据以太网的标准来设置。以太网标准规定，一个网络帧最大为 1518B，那么去掉以太网头部的 18B 后，剩余的 1500 就是以太网 MTU 的大小。
 在使用 VXLAN、GRE 等叠加网络技术时，要注意，网络叠加会使原来的网络包变大，导致 MTU 也需要调整。
 比如，就以 VXLAN 为例，它在原来报文的基础上，增加了 14B 的以太网头部、 8B 的 VXLAN 头部、8B 的 UDP 头部以及 20B 的 IP 头部。换句话说，每个包比原来增大了 50B。
 所以，我们就需要把交换机、路由器等的 MTU，增大到 1550， 或者把 VXLAN 封包前（比如虚拟化环境中的虚拟网卡）的 MTU 减小为 1450。
 另外，现在很多网络设备都支持巨帧，如果是这种环境，可以把 MTU 调大为 9000，以提高网络吞吐量。
 
第三种，从 ICMP 的角度出发，为了避免 ICMP 主机探测、ICMP Flood 等各种网络问题，你可以通过内核选项，来限制 ICMP 的行为。
 
比如，你可以禁止 ICMP 协议，即设置 net.ipv4.icmp_echo_ignore_all = 1。这样，外部主机就无法通过 ICMP 来探测主机。
或者，你还可以禁止广播 ICMP，即设置 net.ipv4.icmp_echo_ignore_broadcasts = 1。

 链路层
 
负责网络包在物理网络中的传输，比如 MAC 寻址、错误侦测以及通过网卡传输网络帧等。自然，链路层的优化，也是围绕这些基本功能进行的。接下来，我们从不同的几个方面分别来看。
 
由于网卡收包后调用的中断处理程序（特别是软中断），需要消耗大量的 CPU。所以，将这些中断处理程序调度到不同的 CPU 上执行，就可以显著提高网络吞吐量。这通常可以采用下面两种方法。
 
比如，你可以为网卡硬中断配置 CPU 亲和性（smp_affinity），或者开启 irqbalance 服务。
再如，你可以开启 RPS（Receive Packet Steering）和 RFS（Receive Flow Steering），将应用程序和软中断的处理，调度到相同 CPU 上，这样就可以增加 CPU 缓存命中率，减少网络延迟
另外，现在的网卡都有很丰富的功能，原来在内核中通过软件处理的功能，可以卸载到网卡中，通过硬件来执行。
 
TSO（TCP Segmentation Offload）和 UFO（UDP Fragmentation Offload）：在 TCP/UDP 协议中直接发送大包；而 TCP 包的分段（按照 MSS 分段）和 UDP 的分片（按照 MTU 分片）功能，由网卡来完成 。
GSO（Generic Segmentation Offload）：在网卡不支持 TSO/UFO 时，将 TCP/UDP 包的分段，延迟到进入网卡前再执行。这样，不仅可以减少 CPU 的消耗，还可以在发生丢包时只重传分段后的包。
LRO（Large Receive Offload）：在接收 TCP 分段包时，由网卡将其组装合并后，再交给上层网络处理。不过要注意，在需要 IP 转发的情况下，不能开启 LRO，因为如果多个包的头部信息不一致，LRO 合并会导致网络包的校验错误。
GRO（Generic Receive Offload）：GRO 修复了 LRO 的缺陷，并且更为通用，同时支持 TCP 和 UDP。
RSS（Receive Side Scaling）：也称为多队列接收，它基于硬件的多个接收队列，来分配网络接收进程，这样可以让多个 CPU 来处理接收到的网络包。
VXLAN 卸载：也就是让网卡来完成 VXLAN 的组包功能。
对于网络接口本身，也有很多方法，可以优化网络的吞吐量。
 
比如，你可以开启网络接口的多队列功能。这样，每个队列就可以用不同的中断号，调度到不同 CPU 上执行，从而提升网络的吞吐量。
再如，你可以增大网络接口的缓冲区大小，以及队列长度等，提升网络传输的吞吐量（注意，这可能导致延迟增大）。
还可以使用 Traffic Control 工具，为不同网络流量配置 QoS

 最后一种极限场景
 
在单机并发 1000 万的场景中，对 Linux 网络协议栈进行的各种优化策略，基本都没有太大效果。因为这种情况下，网络协议栈的冗长流程，其实才是最主要的性能负担。可以用两种方式来优化。
 
使用 DPDK 技术，跳过内核协议栈，直接由用户态进程用轮询的方式，来处理网络请求。同时，再结合大页、CPU 绑定、内存对齐、流水线并发等多种机制，优化网络包的处理效率。
使用内核自带的 XDP 技术，在网络包进入内核协议栈前，就对其进行处理，这样也可以实现很好的性能。
  
 
 
 
 
 
 
 
 
 

目录
 
CPU性能指标
 
性能工具
 
如何迅速的分析CPU性能瓶颈
 
性能优化方法论
 
CPU优化
 
参考
 

 
 

CPU性能指标
 
CPU使用率
 1.CPU使用率描述了非空闲时间占总CPU时间的百分比，根据CPU上运行任务的不同，又被分为
    用户CPU，系统CPU，等待I/O CPU，软中断和硬中断等
 2.系统CPU使用率，表示CPU在内核态运行时间的百分比(不包括中断)，系统CPU使用率搞说明内核比较繁忙
 3.等待/IO的CPU使用率，iowait，表示等待I/O的时间百分比，iowait高说明系统与硬件设备的I/O交互时间比较长
 4.软中断和硬中断的CPU使用率，分别表示内核调用软中断处理程序，硬中断处理程序的时间百分比，他们的使用率高，通常说明系统发生了大量的中断
 5.虚拟化中的窃取CPU使用率(steal)，表示被其他虚拟机占用的CPU时间百分比
 6.客户CPU使用率(guest)，运行客户虚拟机的CPU时间百分比
 

 平均负载(load average)
 也就是系统平均活跃进程数，它反映了系统的整体负载情况，主要包括三个数值，分别指过去1分钟，过去5分钟，过去15分钟的平均负载
 

 上下文切换
 1.无法获取资源而导致的自愿上下文切换
 2.被系统强制调度导致的非自愿上下文切换
 上下文切换，本身是保证linux正常运行的一项核心功能，但过多的上下文切换，会将原本运行进程的CPU时间，消耗在寄存器，内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成为性能瓶颈
 

 CPU缓存的命中率
 由于CPU发展的速度远快于内存的发展，CPU的处理速度也就比内存的访问速度快很多，这样CPU在访问内存的时候，免不了等待内存的响应，为了协调者两者的性能差距，CPU缓存(通常是多级缓存)就出现了
 
 
 
关于CPU性能分析的 指标筛选清单
 
 
 
 
 
 
性能工具
 
把性能指标和性能工具联系起来
 1.从CPU的性能指标出发，当需要查看某个性能指标时，要清朝哪些工具可以做到
 要根据不同的性能指标，对提供指标的性能工具进行分类和理解，在实际派出性能问题时，就可以清楚知道，什么工具可以提供你想要的指标，而不是毫无根据的挨个尝试，
 比如top发现了软中断CPU使用率高后，下一步就需要知道具体的软中断类型，/proc/softirqs
 比如找到软中断类型是网络接收，那就继续往网络接收方向思考，系统网络接收情况是什么样，什么工具可以查看网络接收情况
 
根据指标查找工具
 
 
2.从工具出发，当安装了某个工具后，要知道这个攻击能提供哪些指标
 在生产环境中，可能没有权限安装新的工具包，只能最大化利用好系统中已经安装好的工具，这就需要你对他们又足够的了解
 具体到每个攻击的使用方法，一般都支持丰富的配置选项
 
 
 
 
 
 
如何迅速的分析CPU性能瓶颈
 
实际生产环境中，我们都希望尽可能快的定位系统瓶颈，然后尽可能快的优化性能
 虽然CPU性能指标很多，但他们并不是完全孤立的，很多指标间都有一定的关联，要弄清性能指标的关联性，就要知道每种性能指标的工作原理
 
可以通过 top，vmstat，pidstat 这三个工具来排查问题，因为这三个工具支持很多指标
 
top，vmstat，pidstat 分别提供了重要的CPU指标，并通过虚线表示关联关系
 1.从top的输出可以得到各种CPU使用率以及僵尸进程和平均负载等信息
 2.从vmstat的输出可以得到上下文切换次数，中断次数，运行状态和不可中断状态的进程数
 3.从pidstat的输出可以得到进程用户CPU使用率，系统CPU使用率，自愿上下文切换和非自愿上下文切换情况
 
比如
 1.top发现用户CPU使用率有问题，可以用pidstat接着分析是哪个进程导致的
 2.top的平均负载比较高，可以跟vmstat的运行状态和不可中断状态进程数做对比，观察是哪种进程导致的负载升高
 3.当top输出的软中断CPU使用率升高，可以查看/proc/softirqs中的各种类型软中断变化情况，确定是哪种软中断出的问题，比如发现网络接收中断导致的问题，可以继续用sar和tcpdump分析
 
 
 

性能优化方法论
 
1.要做性能优化，怎么判断它是不是有效？特别是优化之后，能提升多少性能？
 2.性能问题通常不是独立的，如果有多个性能问题同时发生，应该先优化哪一个？
 3.提升性能的方法并不是唯一的，当有多种方法可以选择时，选用哪一种？是不是总选能最大程度提升性能的方案？
 
比如前面例子中的一个进程使用直接I/O导致iowait很高，如果将直接I/O改成缓存I/O呢？对于上面的三问就是
 1.直接I/O换成缓存I/O，可以把iowait从90%降低到接近0，性能提升很明显
 2.没有发现其他性能问题，直接I/O是唯一的性能瓶颈，所以不用挑选优化对象
 3.缓存I/O是目前用到的最简单的优化方法，而且这样优化并不会影响应用的功能
 但实际情况中，性能评估可能有多重指标，性能问题可能会多个同时发生，而且优化某一个指标的性能，可能又会导致其他指标性能的下降
 

评估性能优化的效果
 需要对系统的性能指标进行量化，并且要分别测试出优化前，优化后的性能指标，用前后指标的变化来对比呈现效果
 1.确定性能的量化指标
 2.测试优化前的性能指标
 3.测试优化后的性能指标
 
对于第一点，性能的量化指标有很多，比如CPU使用率， 应用程序的吞吐量，客户端请求延迟等都可以评估性能指标，所以不要局限在单一围堵指标上，至少要从应用程序和系统资源两个维度，分别选择不同的指标，以Web应用为例子
 应用程序维度，可以用 吞吐量和请求延迟 来评估应用程序的性能
 系统资源维度，可以用 CPU使用率 来评估系统的CPU使用情况
 
应用程序和系统资源这两者之间是相辅相成的
 好的应用程序是性能优化的最终目的和结果，系统欧化总是为应用程序服务的，所以必须要使用程序的指标，来评估性能优化的整体效果
 系统资源的使用情况是影响应用程序性能的根源，需要用系统资源的指标，来观察和分析瓶颈的来源
 
性能测试的时候需要注意
 1.避免性能测试工具干扰应用程序的性能
 2.避免外部环境的变化影响性能指标的评估，这要求优化前，优化后的应用程序，都允许在相同配置的机器上，并且他们的外部依赖也要完全一致
 

多个性能问同时存在时的选择
 根据二八原则，找出20%的位置，就可以优化80%的性能，所以并不是所有性能问题都值得优化
 在优化之前应该把所有性能问题分析一遍，找出最重要的，可以最大程度提升性能的问题，从它开始优化。怎么判断哪个性能问题最重要，有一个简化的判断过程
 1.如果发现系统资源达到了瓶颈，比如CPU使用率是100%，那么首先优化的一定是系统资源使用问题，
   完成系统资源瓶颈的优化后，我们才要考虑其他问题
 2.针对不同类型的指标，首先去优化那些由瓶颈导致的，性能指标变化幅度最大的问题，比如生产瓶颈
   后用户CPU使用率升高了10%，而系统CPU使用率却升高了50%，这个时候就应该首先优化系统CPU使用
 

多种优化方法时的选择
 理论上就应该选择提升性能最大的方法，但性能优化并非没有成本，性能优化会带来复杂度的提升，降低程序的可维护性，还可能在优化一个指标时，引发其他指标的异常
 比如DPDK(Data Plane Development Kit)，DPDK是一种优化网络处理速度的方法，它绕开内核网络协议栈的方法，提升网络的处理能力，但他要求独占一个CPU一级一定数量的内存大页，并且总是以100%的CPU使用率运行，所以如果CPU核数很少就不行了
 选择性能优化方法时，就要综合考虑，不能一步登天，试图解决所有问题
  
 
 
 
CPU优化
 
应用程序优化
 从应用程序角度来说，降低CPU使用率的最好方法是派出所有不必要的工作，只保留最核心的逻辑，减少循环次数，减少递归，减少动态内存分配等，常见的优化如下
 1.编译器优化，比如gcc -O2 选项，开启后会自动会应用程序的代码进行优化
 2.算法优化，使用复杂度耕地的算法，可以加快处理速度，如O(nlongn)的排序算法
 3.异步处理，避免程序因为等待某个资源而一直阻塞，从而提升程序的并发处理能力，比如把轮询改为
   事件通知，就可以避免轮询消耗CPU的问题
 4.多线程替代多进程，相对于进程的上下文切换，线程的上下文切换并不切换进程的地址空间，可以
   降低上下文切换的成文
 5.善用缓存，经常访问的数据或计算过程中的步骤，可以放到内存中缓存起来
 
系统优化
 从系统的角度来说优化CPU的运行，一定要充分利用CPU缓存的本地性，加速缓存访问，另一方面要控制进程的CPU使用情况，减少进程间的相互影响
 具体来说，有如下方法
 1.CPU绑定，把进程绑定到一个或多个CPU上，可以提高CPU缓存的命中率，减少跨CPU调度带来的上下
   文切换问题
 2.CPU独占，跟CPU绑定类似，进一步将CPU分组，并通过CPU亲核性机制为其分配进程，这些CPU就由
   指定的进程独占，不允许其他进程再来使用这些CPU
 3.优先级调整，使用nice调整，正值调低优先级，负值调高优先级
 4.位进程设置资源限制，使用cgroups来设置进程的CPU使用上线
 5.NUMA(Non-Uniform Memory Access)优化，支持NUMA的处理器会被划分为多个node，每个node都有与
   自己的本地内存空间，NUMA优化就是让CPU尽可能只访问本地内存
 6.中断负载均衡，无论是软中断还是硬中断，他们的中断处理程序都可能会耗费大量的CPU，开启
   irqbalance服务或者配置 smp_sffinity，就可以把中断处理过程自动负载均衡到多个CPU上
  
 
 
 
避免过早优化
 
高德纳的名言，过早优化是万恶之源
 优化会带来复杂性的提升，降低可维护度，另外需求不是一成不变的，针对当前情况进行的优化，很可能并不适应快速变化的新需求，在新需求出现时，这些复杂的优化，反而可能阻碍新功能的开发
 所以，性能优化最好是逐步完善，动态进行，不追求一步到位，而要首先能保证蛮族当前的性能要求，当发现性能不满足要求或者出现性能瓶颈时，再根据性能评估的结果，选择最中意的性能问题进行优化
 
 
 
 
 
 
 
 
 
参考
 
hping3
 
perf tool 
 
sysbench
 
stress