Posts tagged OceanBase

多存储设备混合使用raid卡配置问题

5

背景说明:

oceanbase的updateserver服务使用了SAS+SSD的混合存储方式,其中SAS盘用于存储实时记录的操作日志,SSD用于存储定期转储的内存数据。updateserver写操作日志的特点是大量的小块数据追加写,总带宽不大,但是要求1毫秒以下的写延迟,直接使用SAS或SSD都无法满足需求,因此我们为updateserver配备了一块带电池的raid卡,数据写入raid卡的缓存后即向系统返回,再由raid聚集后再写入SAS盘。在线上的配置中,SAS盘和SSD盘都接到同一块raid卡上。

问题说明:

oceanbase在sns feed index机群调高写入压力后,偶尔出现写操作日志用时超长的情况,由于updateserver机器配置了带电池的raid卡,正常情况下数据写入raid卡的buffer即可返回,用时约100us,但是在sns feed index的应用中却出现主备写操作日志用时达到几百毫秒的情况,由于updateserver使用单线程批处理写请求的技术,所以一次写操作日志的超时就会造成后续排队中的写任务延迟都相应增加,短时间内阻塞应用端很多数据的写入。

经过排查发现线上两次出现的这种写超时情况,都伴随同时在执行的updateserver转储任务,通过与内核组高阳同学的多次交流,怀疑转储写SSD的IO影响了写操作日志,造成其延迟增大,在线下部署与线上相同的压力测试环境,sas盘做raid1,2块ssd不做raid,全接到raid卡上,写入模式都为write back,在7500TPS,写操作日志速度约25MB/s,转储写SSD速度约100MB/s的情况下,稳定复现这一问题。

统计测试结果发现,出现超时的概率与ssd的碎片情况有关,在ssd没有经过全盘dd碎片比较多的情况下,写操作日志用时超过50ms的概率为万分之3.2,而对ssd进行一次全盘dd置零之后,仍然会出现写操作日志用时超过50ms的情况,但是概率降低到百万分之1.7。使用megacli将ssd设备的写入模式修改为write through之后,再进行测试连续写入500G数据的情况下,超过50ms的情况出现次数为0。

因此实验数据验证了之前的怀疑,由于写操作日志和转储数据都是write back模式,先放在raid的卡的缓存中,然后异步写到设备中去,由于转储短时间内写数据量比较大,在写满raid卡缓存的情况下,只能阻塞写入,等缓存的数据写到设备中去才能返回,这样缓存就退化成了一个fifo队列,阻塞了写操作日志的IO,特别是在SSD碎片比较多的情况,写SSD变造成raid卡缓存清理耗时变长,写操作日志用时也相应变长。

结论:

1、updateserver使用的机器,上线前需要对raid进行配置,除操作日志盘的写入模式为write back,其他盘需要改为write through

2、ssd盘上线前做一次全盘清理,使用dd即可(dd if=/dev/zero of=[ssd设备文件] bs=4194304)

OceanBase的变化

7

OceanBase面临的新挑战

  随着OceanBase(以下简称OB)在淘宝的应用越来越广泛,前端对数据的需求也提出了越来越严苛的要求。在应用系统和开发团队的配合下,给用户提供了很多额外的功能,给用户带来方便的同时,也给OB带来了很多的挑战。
  以淘宝的收藏夹应用为例,从4月份上线到现在,我们增加了2倍的数据表,数据量(包括数据条目和每日更新条目)是上线初期的4倍,访问量是上线初期的8倍以上。 (更多…)

OceanBase介绍

46

OceanBase是什么

  OceanBase是一个支持海量数据的高性能数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。

OceanBase解决什么问题

  许多公司的核心资产是各种各样的商业数据,例如淘宝的商品、交易、订单、购物爱好等等,这些数据通常是结构化的,并且数据之间存在各种各样的关联,传统的关系数据库曾经是这些数据的最佳载体。然而,随着业务的快速发展,这些数据急剧膨胀,记录数从几千万条增加到数十亿条,数据量从百GB增加到数TB,未来还可能增加到数千亿条和数百TB,传统的关系型数据库已经无法承担如此海量的数据。许多公司,尤其是互联网公司,正在探索各自的解决之路。 (更多…)

Go to Top