我们在Amazon EC2 / Rightscale m1.large实例上的单节点cassandra上有以下统计信息，其中包含2个带raid0的短暂磁盘。 （7.6 GB总内存）
4 GB RAM分配给cassandra堆，800MB是堆新大小。
以下统计信息来自OpsCenter社区2.0
每秒读取请求285到340
每秒写入请求257到720
OS Load 15.15至17.15
写请求延迟293到685微
郎
操作系统发送网络流量18 MB至30 MB /秒
OS已接收网络流量22 MB至34 MB /秒
操作系统磁盘队列大小23到26个请求
阅读待审8至20的请求
读取请求延迟69140至92885微型
操作系统磁盘延迟37到42毫秒
OS磁盘吞吐量每秒12到14 Mb
磁盘IOP每秒读取600至740次
磁盘IOP每秒写入2到7次
IOWait 60％到70％的CPU平均值
空闲24至30％CPU平均值
Rowcache已停用。
以上统计数据是否满足于所提供的配置....或者我们如何调整它以获得更少的IOWait ..........因为我们认为我们遇到了很多IOWait .. ...我们怎么能调整它以获得最佳效果。
读取请求是混合的......有些来自一个超级列系列，一个标准有超过百万个键......并且不同。超级列最大14与不同的。子列的数量从1到10000并且不同。标准列族中的最大列数为14 ............... subcolumns本质上非常薄，0字节值.... 8字节用于名称。
进程正在从超级列族中删除数据，并将处理后的数据写入标准列。
EBS磁盘能否在Amazon EC2上更好地工作
答案 0 :(得分：4)
我不能肯定你是否可以轻松调整你的配置以获得更多的磁盘性能，但使用Snappy压缩可以帮助你做一个很好的应用程序，让你的应用程序需要更少的整体阅读。它可能也有助于使用新的复合键布局而不是超级列。
我可以肯定地说一句话：EBS将 NOT 更好地工作。如果您关心延迟，请不惜一切代价远离它。