云服务器磁盘IO问题的思考
回4楼appayud1v的帖子
redis内存数据库dump应该是大块io写吧,平均io块大小及吞吐量有多少?如果当前的磁盘性能不足,可考虑用4块磁盘做raid0来聚合性能。
-------------------------
回3楼overlook的帖子
写一份成功就返回,对时延有一定的帮助,但是可靠性大打折扣。
在第一份数据返回成功后、第二份数据备份完全前,如果第一份数据所在的设备crash掉了,业务就中断了。像阿里云这么大规模的云计算场景,出现这类异常还是很容易的,毕竟硬件有一定的故障率,很难避免。
-------------------------
回楼主at6569s2r的帖子
ucloud采用本地存储的方案,在该方案中有两层存储,第一层是基于内存的cache,第二层是SATA存储,通过后台任务将cache中的数据刷到SATA盘中;ucloud性能高是指纯写(100%)的场景,能将所有的写io落在cache中,从而达到性能不错的效果;这种方案有致命的缺陷 :
1.数据可靠性:当cache中有未刷到SATA盘的脏数据时,出现机器crash,数据必丢失;一般的x86硬件(包括整机及机械硬盘)都存在0.02%的故障率,这种本地存储+cache提升性能的存储方案一定会出现宕机数据丢失的情况。
2.运维管理成本高:单台物理机的cache毕竟有限,它不可能将vm所有的写io数据都能存在cache中,一旦有io未落cache而落SATA盘,性能将出现数量级的下降;如果是客户关键业务遇到这种情况,将不可接受;要解决这个问题,只能是迁移vm及数据;由于是本地存储,迁移vm必然要迁移数据,此时又会消耗大量的物理机网络带宽及cpu资源,进而影响其他的vm运行且迁移时长不可控;同时,这种迁移必然是手工的,难于做到自动化,运维管理成本高可想而知;
3.场景非常有限:1)对于只读io场景,特别是随机读io,由于cache难于做到随机读命中,此方案中的cache对读io就失效,性能就回归SATA盘的能力;2)对于随机读写混合场景,由于读做不到cache命中,读时延上升导致写时延也上升,结果是cache失效。在实际应用环境下,100%的写io场景是相对较少的,大部分还是读写混合场景。
-------------------------
回9楼overlook的帖子
io策略可配置的方式对用户技术水平要求较高。相比传统IT,云计算一大好处是将用户从IT运维管理中解放出来从而聚焦自己的业务;io策略可配置可能对少数高手来说有定制化的手段,但对大部分不那么高手的用户来说可能会带来麻烦。从云计算平台来看,这种方式会带来额外的异常处理及运维管理成本。
-------------------------
回10楼stonys的帖子
你现在的业务需要怎样的性能?比如需要多少IOPS、多少BPS等
赞0
踩0