storforward_个人页

回楼主zjwxww的帖子 块大小多大？不同的块大小对性能结果有很大的影响。另外，这个工具好像只能单路并发读写，如果要压测性能，最好选择能多路并发的测试工具，如FIO。

回52楼high飞起的帖子 虽然微软SSD盘是免费的，但其售价捆绑到实例里面了，羊毛出在羊身上。

Re分享业务场景赢取SSD公测资格更有多重好礼等你拿 哇塞，这个必须赞，赶快抢啊~~

回楼主zjwxww的帖子 你现在用的实例配置是怎样的？2核CPU|4GB内存？

回17楼wpwcn的帖子 如果知道会使用多少流量，可采用“按使用流量” 的方式购买带宽

回4楼呼呼小半仙的帖子 要看什么样的企业。像四大行，每个省分公司的数据都是PB级别。

回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等