性能分析与优化

测试种类

在这里插入图片描述

在这里插入图片描述

压力测试

  • 压力测试是评估系统处于或超过预期负载时系统的运行情况
  • 在压力级别逐渐增加时,系统性能应该按照预期缓慢下降,但是不应该崩溃
  • 压力测试还可以发现系统崩溃的临界点,从而发现系统中的薄弱环节

性能数值

IO

在这里插入图片描述

  • IO 读写延迟:一般是用 4KB 大小的 IO 做基准来测试
    • 如果一个随机 8KB 或 16KB 数据的对硬盘的读写,测量出的延迟不到 1 毫秒,那就实在是“太快”了;可以肯定它是命中某种缓存了
  • IO 带宽:一般是针对比较大的 IO 而言;
  • IOPS:就是每秒钟可以读写多少个小的随机 IO

缓存

在这里插入图片描述

操作系统

  • 指令分支预判错误:10ns
  • 互斥锁加、解锁:10ns
  • 上下文切换:1us

网络

  • 200 毫秒延迟,是多数在线用户可以忍受的最大延迟

  • RTT与距离的关系:每100公里增加1ms
    在这里插入图片描述

性能指标

在这里插入图片描述

在这里插入图片描述

  • 最核心的几个个性能指标:TPS,RS和错误率
  • 服务延迟
    • 指的是客户发出的请求被成功服务的时间
  • 吞吐率
    • 指的是单位时间(比如每秒钟)可以成功处理的请求数或任务数
    • 如果吞吐率很低,服务延迟往往会非常稳定。当吞吐率增高时,访问延迟一般会快速增加

在这里插入图片描述

  • 资源使用率
    • 直接决定了系统和服务的运营成本

性能瓶颈

在这里插入图片描述

CPU

  • 超线程
    • 当处理器在运行一个线程,执行指令代码时,很多时候处理器并不会使用到全部的计算能力,部分计算能力就会处于空闲状态
    • 比如一个线程运行过程中,必须要等待一些数据加载到缓存中以后才能继续执行,此时 CPU 就可以切换到另一个线程,去执行其他指令,而不用去处于空闲状态,等待当前线程的数据加载完毕
    • 一个传统的处理器在线程之间切换,可能需要几万个时钟周期
      • 而一个具有超线程技术的处理器只需要 1 个时钟周期。因此就大大减小了线程之间切换的成本,从而最大限度地让处理器满负荷运转
  • 因为 CPU 架构的复杂性,以及和其他部件的交互,CPU 的使用率和负载的关系往往不是线性的
    • 如果 10% 的 CPU 使用率可以每秒处理 1 千个请求,那么 80% 的 CPU 使用不太可能处理每秒 8 千个请求,往往会远远小于这个数字
  • 和 CPU 相关的性能问题,基本上就是表现为 CPU 超载或者空闲
    • CPU 超载多数情况下都不一定是合理的超载,比如说多核之间的负载没有平衡好,或者 CPU 干了很多没用的活
    • CPU 空闲或许是指令里面太多内存数据操作,从而造成 CPU 停顿,也或许是太多的分支预测错误

内存

  • 内存访问带宽

    • 单位时间内,可以并行读取或写入内存的数据量,通常以字节 / 秒为单位表示
    • 当内存带宽较小时,内存访问延迟很小,而且基本固定,最多缓慢上升。而当内存带宽超过一定值后,访问延迟会快速上升,最终增加到不能接受的程度
    • 内存总带宽的大小一般是四个因素的乘积
      • DRAM 时钟频率、每时钟的数据传输次数、内存总线带宽(一般是 64 字节)、内存通道数量
  • L3缓存命中的失效不仅会导致内存访问延迟,还会受限于内存带宽
    在这里插入图片描述

  • 应用程序向操作系统申请内存时,系统需要查找可用内存并分配,这中间总要花些时间

    • 一个系统的空闲内存越多,应用程序向操作系统申请内存的时候,就越快地拿到所申请的内存。反之,应用程序就有可能经历很大的内存请求分配延迟
    • 在系统空闲内存很少的时候,程序很可能会变得超级慢。因为操作系统对内存请求进行(比如 malloc())处理时,如果空闲内存不够,系统需要采取措施回收内存,这个过程可能会阻塞
  • 直接使用 new、malloc 等 API 申请分配内存,所申请内存块的大小不定。当这样的内存申请频繁操作时,会造成大量的内存碎片;这些内存碎片会导致系统性能下降

    • 开发应用程序时,采用内存池(Memory Pool)可以看作是一种内存分配方式的优化
    • 这样做的一个显著优点是尽量避免了内存碎片,使得内存分配效率和系统的总体内存使用效率得到提升

网络

  • 常用指标:可用性,响应时间,带宽容量,吞吐量,网络利用率
    在这里插入图片描述
  • 多层次网络结构中,一般是越往上层,总的带宽越少
    • 因为多数的数据交换是在内部进行的,不会全部都和外部进行交换
    • 不要让高层的网络带宽成为性能瓶颈
      • 尽量让有大量数据交换的服务在一起部署(比如部署在同一个机架内)
      • 比如假设两个服务分别用不同的服务器,它们之间的数据交换如果很多的话,就尽量让它们运行在同一个机柜的服务器里面;如果不能保证同一个机柜,就尽量是同一个 POD 内部
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章