在0.3版本的时候,线上的系统还是大部分用的sata,sas盘,后来由于读写速度的问题(主要是每日合并的要求),到0.5版本的时候,大部分线上系统已经采用了SSD。

大部分系统是这样的情况,如果使用sata盘,那么性能瓶颈在磁盘,如果使用ssd,性能瓶颈在CPU(性能优化还没做的足够好的表现)
关于SSD的基础知识的介绍,见以前的博客:

  • linux优化使用ssd的方法
  • SSD基础知识
  • SSD顺序写对随机读的影响
  • IO调度算法

机器选型

ups最初使用的机型是搭载一块sas盘(用于ups写日志),4块ssd盘(用于转储)。写日志盘使用sata盘的原因是,日志通常的是小块的写,而SSD对于小块写有写入放大,达不到性能要求。这样可以满足需求,但是问题来了,这种机型在市场上的选择太少了,只有惠普有,而作为一个大公司,又不可能自己去DIY这种机型(没法保修啊);

ups后来就放弃这种机型了,开始使用raid卡,raid卡后,再挂ssd,raid是有掉电保护的,它可以将日志批量写到磁盘。当然raid卡有充放电的问题,充放电期间对性能是有影响的,所以会放在业务低峰期间进行

cs的机型要么挂载10块sata盘,要么挂载10块ssd盘,没有使用raid卡

日志问题

上面提到ups使用raid卡解决了日志的写问题。

而cs没有配置raid卡(成本问题),但是cs也需要写日志,cs写日志的最初设计是每写2M的块都要写一条日志,在测试中,发现这确实成为了每日合并时候的瓶颈;优化方法是使以tablet为单位(256M),批量刷日志,缓解了这个问题

文件系统的问题

文件系统不仅会写数据,还会写元数据,而元数据一般是小块的随机写,这对于ssd来说,因为有写入放大的存在,会导致性能下降,所以线上系统要尽量避免一些不必要的元数据的写入,比如noatime(文件的最后访问时间)在线上挂载时一般是打开这个选项的。

写入块大小的问题

早期的sstable版本并没有针对ssd做优化,写入的单位的micro block(16K左右,不是固定大小),这对于ssd来说并不是友好的,所以后来在0.5的sstable中,写入的单位统一改为2M(固定大小)

wear leveling的问题

ssd都有wear leveling机制,预留一部分空间做负载均衡,防止每一部分擦写过多,导致ssd挂掉;0.5使用blocksstable(一个大文件),并不会占用所有磁盘空间,而是占用90%,也是出于这方面的考虑

trim机制

简单来说就是文件系统,通知磁盘哪些块已经被删除,可以做垃圾回收了,对于ssd来说,这非常重要,因为可以提前擦除,防止再次写入时,要先擦除再写入,不过在oceanbase集群中没有对此做配置

分区对齐

挂载的ssd盘的分区,最好以512K或2M对齐,减少写跨分区的情况。

调度算法

线上的ssd集群一般使用的deadline算法,在实际测试中,它与noop算法的性能表现是一样的,原来也很清楚,ssd没有大量寻址的开销。

每日合并对ssd寿命的影响

每次每日合并都涉及大量磁盘块的写入,所以要尽量减少写的块的数量(0.5以2M块来决定是否要重写,以前是256M),尽量避免全量合并(渐近合并)

其它

以前专门用fio对intel,sansung,华为的ssd做过测试。
intel的响应时间非常稳定,但价格比较贵,华为的也可以,sansung表现的很差,甚至出现过上百ms的情况。

Comments