大数据系统性能分析

jojoster / / 技术

大数据系统性能分析

单机瓶颈分析

增加并发和吞吐

增加并发的方式

  • 主要是增加对CPU的利用
  • 多机
  • 单机多CPU
  • 单CPU多core
  • 单core超线程

方法

  • IO密集型应用：降低线程切换对cpu的浪费
  • 多进程 – 多线程 – 事件驱动 – 协程
  • CPU 密集性应用：增加计算的并发
  • 多进程 – 多线程
  • 除非资源到了瓶颈，否则不排队
  • 合适的并发模型
    • 比如ependingpool、事件触发、异步队列等
  • 队伍要均衡
    • 保证能够打到充分的并发
  • 过长的队伍、及时柔性处理（可丢服务）
    • 大数据系统中经常遇到数据堵塞等场景，需要有良好的柔性处理机制，如优先级机制，清除过期数据的机制，部分服务可丢等机制来解决
  • 能并发的任务不串行
  • 并发情况下，影响等待时间的主要是最长的任务时间
  • 串行情况下，是所有任务时间之和

去除不必要的动作

  • 减少网络重连
  • 长连接
  • 降低连接数
  • 连接池
  • 减少线程切换
  • 线程池
  • 减少内存分配和释放
  • 内存池
  • 减少耗时的操作合运算
  • memset，浮点运算，除法，指数，对数运算，慎用 stl
  • 在线转离线
  • 离线提前进行耗时运算

避免冲突

  • 多线程无锁算法
  • 无锁共享数据、无锁数据结构、Copy on write，更新不影响读取
  • HASH冲突解决（经常遇到由于hash冲突或者锁冲突导致的性能下降）
  • 合理的使用锁
    • 锁的时间尽可能短
    • 降低冲突概率
    • 避免死锁
    • 锁的影响范围尽可能小：blockingQueue的分段锁机制

IO优化

关于磁盘I/O的性能，引用一组Kafka官方给出的测试数据(Raid-5，7200rpm)

  • SequenceI/O: 600MB/s
  • RandomI/O: 100KB/s

随机修改

  • WAL(write ahead
    logging)：随机写入转化为顺序的写入，写入成功即可返回，在故障时候通过 log 恢复
  • LSM-Tree：适合的应用场景：insert数据量大，读、update数据量不高，并且一般针对最新数据
  • 方法：写入数据到内存即返回，缓冲到一定量再写入磁盘；读取时候需要merge磁盘读取合内存中的内容(bigtable,
    tera)
  • 减少IO次数，批量去重
  • 适用于请求中重复度较高的，如链接库的写入，后链的特点就是重复度很高，批量去重能够去除较大部分的重复数据，降低对后端服务的io压力

随机读取

  • 尽量减少IOPS，无cache的情况下做到每请求只消耗1IO
  • 通过优化cache淘汰算法提高cache命中率
  • 基于统计的淘汰策略
  • 多级LRU队列
  • 合理李勇Flash存储，通过压缩等手段降低Flash压力

其他

  • 预处理，预充Cache，预热再服务
  • 充分利用硬件
  • 存储速度: 内存 >> SSD >> sata
  • 示例：kafka （顺序读写 + page cache）
    • 顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证
    • 充分利用pagecache，直接内存读取直接发送

集群瓶颈分析

减少数据传输量

数据压缩-CPU与网络io的权衡

  1. 减少跨机房io
  2. 打包访问
  3. 减少交互次数
  4. 数据压缩：CPU与网络IO的权衡

压缩算法对比

数据来自于hbase
| 算法 | remaining(%) | Encoding | Decoding |
| ———— | ———— | ——– | ——– |
| GZIP | 13.4% | 21MB/s | 118MB/s |
| LZO | 20.5% | 135MB/s | 410MB/s |
| Zippy/Snappy | 22.2% | 172MB/s | 409MB/s |

Snappy 在 Google 内部被广泛的使用，从 BigTable 到 MapReduce 以及内部的 RPC
系统

均衡

  1. 负载均衡，常用，一个好的负载均衡方法是保证整个分布式系统性能的基础

  2. RR，Random，Locality-aware，hash

  3. 热点+打散

  4. 自动拆分和融合节点

  5. 自动伸缩容量，弹性

  6. 消除长尾（比如分布式系统中有一个实例老是响应时间长，此时可以屏蔽这个节点）

  7. 拆分、并发

  8. 消峰、限流、缓冲+延迟处理（优先级机制）

1.
消息队列中使用优先级方式，可以一方面保证高优请求很快得到处理，另一方面达到全局缓冲

  1. 丢弃、降级服务

  2. 丢弃是说检测到服务扛不住的时候，自动丢弃一些请求
    2.
    降级这里说的是人工方式处理，比如搜索服务中，在高峰期可以关闭广告处理、甚至关闭另一个引擎

案例：mr任务老是跑很长时间，个别子分片总是运行不完

均匀分片

擅用cache

cache种类
  1. 内存 cache、分布式cache
  2. 有结果 cache/ 无结果cache/ 超时cache
  3. 只读cache/ 读写 cache
提升命中率
  1. 合理的cache key 设计

  2. 需要全局考虑一下，兼容各种访问

  3. 有效的淘汰算法

  4. 保存命中率高的item

案例：上游hash寻址下游（us寻址gss）

  1. 容易造成热点问题

Cache对延迟的优化效果

  1. 节省大量耗时操作时间：不必要的计算、网络、IO

  2. 案例7 均值200ms的服务，加了cache，命中70%

  3. 200×0.3+1×0.7=67ms

系统优化

容器+混步

  1. IAAS
  2. matrix
  3. PAAS
  4. Jpass
  5. Galaxy
  6. Beehive

全量模型->增量模型

  1. 适用于 全量数据量大，而增量更新比例小的情况
    1. 实例 linkbase3.0，将连接库从全量+patch
      改造为增量实时读写模型，节约8000槽位x36小时的计算资源
    2. spider实时统计策略，从1500太机器节约到500台以下

避免局部瓶颈

分布式环境下，每个子系统都非常重要

​ 木桶效应

案例9：一个分布式系统，消息队列发给模块a，模块a负责读取存储系统，merge数据，在写回存储系统（即
read-modify-write模型），性能非常低，加并发、加机倌增量更新比例小的情况
1. 实例 linkbas点影响了整体服务

分治的方法，让A模块只处理匹配分片的存储资源，不要全局访问节点

这样出现故障的话，不会影响全局的性能

不要牺牲可维护性

​ 尽量避免设计过度复杂的系统，人力成本也是成本，一定要可维护性高

tera + 每秒400W qps

类似 google 的 bigtable

发表评论

邮箱地址不会被公开。 必填项已用*标注