转载

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

【编者的话】闪存在这几年越来越受到大家重视,今天主要介绍一些闪存的应用案例和测试方法。本次分享作者是熊猫tv DBA杨尚刚,2011年加入新浪,负责新浪微博核心数据库架构设计,负责新浪数据库平台底层软硬件平台优化,现在在熊猫TV,负责后端数据库平台建设。

闪存应用场景

- 数据库

- NoSQL

- 分布式存储

- CDN

综合上面几种场景看,闪存主要适合有比较高的随机IO需求和带宽需求的场景。场景选择上,也是要发挥闪存的长处。目前上面业务中 未来几年发展比较快的会是在公有云存储这一部分。下图就是某厂商云盘对比,可以看到闪存的价格已经很接近机械硬盘了,而单从每IOPS成本看,性价比会更高。

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

闪存概述

固态硬盘,不过可以从广义理解,从2010年开始在互联网行业大规模应用,性能和稳定性已经得到大规模集群线上验证,应用场景已经非常广泛。当然闪存的IOPS比传统机械硬盘高几个数量级,但是更核心的还是在延迟降低上,优势更大。

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

上图就很好的说明了,闪存在访问延迟上的提升。

提到闪存,不得不提到闪存里非常基础的组件 NAND。NAND分类现在也是非常多。

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

测试

我们为什么要做测试呢?

  • 了解产品
  • 了解自己
  • 优化自己
  • 优化成本模型

所以说面对如此多的厂商和产品,如何做到更高效的测试 是一个很重要的问题。虽然现在大家都开始转向云服务,直接接触硬件产品并不多,但是云厂商的测试依然是很重要的一部分。

测试很Low吗?

  • 测试很简单?
  • 没科技含量?
  • 测试很无聊?

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

上图是我们需要了解的存储技术栈。

测试准则:

  • 明确目标
  • 高效
  • 完备性
  • 可量化
  • 可对比
  • 产出

测试过程:

  • 明确测试需求
  • 明确测试目标
  • 选择测试工具和测试模型
  • 制定测试计划
  • 测试过程跟踪
  • 测试数据验证
  • 测试报告

测试工具:

  • IO层面:fio,sysbench,iometer,dd等
  • OLTP:sysbench,TPC-C
  • 辅助工具:tcpcopy,tcprstat,pt-log-player

sysbench:

  • 开源的多线程性能测试工具
  • 支持CPU IO Mutex OLTP等测试
  • 可以lua脚本定制测试用例
  • 常用的insert select和oltp三种场景

测试痛点:

  • 重复工作很多
  • 标准不统一
  • 测试周期很长
  • 人工成本高
  • 测试期间异常处理
  • 测试数据处理和测试报告

解决痛点首先就是规范化:

  • 测试目标标准化
  • 测试工具标准化
  • 测试流程标准化
  • 测试报告标准化

自动化测试流程:

  • 自动化测试框架
  • 基于Python
  • 包含整体标准测试流程
  • 覆盖主流测试工具
  • 数据处处理和生成报表
  • 定制测试计划

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

自动化的好处也是显而易见的:

  • 大大节省了人力
  • 提高测试效率
  • 测试的更加完整
  • 有精力做更深入的测试优化

测试闪存需要注意的几点:

我们需要的性能是steady state

  • OP
  • NAND
  • 全盘写
  • 测试时间不能太短
  • 性能抖动
  • 监控

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

MySQL测试的一些问题:

测试数据集大小,至少要过亿

  • 和内存buffer比例,要看在小cache下的性能
  • 物理读
  • 事务复杂度
  • 多表并发

系统层面的一些注意点:

  • 文件系统:Ext4 xfs
  • IO调度算法
  • IO cpu affinity
  • Scsi-mq/blk-mq(新内核特性)

测试优化结合

InnoDB压缩测试:

  • InnoDB内置压缩
  • 基于zlib库
  • 理论可以达到50%左右的压缩比
  • 但是性能有损失
  • CPU时间换存储空间
  • 对SSD寿命有好处
  • 如何用好呢?

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

基于我们之前的测试过程,我们可以得到结论,InnoDB压缩比在50%左右,对写入性能损失比较大, 损失比例在70%左右。根据这个结论,我们就可以针对我们线上业务选择是否需要使用InnoDB压缩。

TokuDB:

  • MySQL的一个存储引擎,支持事务 ACID 特性
  • 支持多版本控制(MVCC)
  • 基于Fractal Tree Index,非常适合写入密集场景
  • 高压缩比
  • 原生支持Online DDL
  • 主流分支都支持
  • 收费 转开源

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

这是我们测试结果,可以看到TokuDB更好的压缩比和更好的写入稳定性,当然代价就是更高的CPU消耗。

总结

  • 现在不再是性能为王的时代
  • 真正了解自己需求才是更重要的
  • 发掘闪存性能,软硬件结合
  • 拓展闪存应用空间
  • 做真正有价值的事情
  • 如何做到更好的软硬件结合(其实现在硬件是超前于一些软件的)

DockOne微信分享(六十七):联网场景下的闪存测试和优化应用

以此图结尾,不要只活在当下,要勇敢的接受新技术,勇于试错,当然试错成本和收益也要评估和可控的。其实很多技术理解透彻了,可能并没有别人说的“邪恶”。

原文  http://dockone.io/article/1518
正文到此结束
Loading...