我们有一个带有小型（15G）EBS驱动器的m1.medium EC2实例，同时运行Rails 3和PostgreSQL服务器。 我们已经注意到在奇怪的时候出现了CPU峰值，最后终于意识到，即使是简单的，持续的EBS访问似乎也会lockingCPU。 例如，只是对日志的3G的grep导致100％的CPU使用率 – 这意味着两个核心，这应该是不可能的grep！ 删除一堆日志文件也使用了大约25％的CPU，这比我所期望的要多。 我们不换。
这是正常的吗？ 对于Google来说这很难，因为“高CPU”也是一种EC2实例的名称。 我会高兴地提供更多的细节和基准，但首先我想检查这是否是一件事情。
EBS卷的性能可能会受到以下情况的影响：
即使从EBS快照创build新EBS卷，也会有第一次使用的惩罚。 第一次读取或写入卷上的每个块需要比后续的点击更长的时间。
当EBS快照启动后，当您尝试写入尚未复制到S3快照存储的块时，EBS卷可能会遇到高Iowait。
EBS卷使用实例上的networking带宽。 如果升级到更大的实例types，则可能会获得更好的IO性能并降低CPU Iowait。
这里有一篇文章是关于从快照中提取EBS卷的延迟加载的：
从EBS快照中识别新的EBS卷已完成初始化
http://alestic.com/2010/03/ebs-volume-initialization-from-snapshot
这里有一篇文章描述了为什么我们必须将EBS快照移动到从数据库，而不是在主服务器上运行它们：
EC2上的MySQL从站数据库的EBS快照
http://alestic.com/2009/08/ec2-mysql-slave-snapshot
在你提到的grep中，几乎所有的CPU时间都可能是由于iowait造成的。 在grep期间在另一个terminal中运行top并观察%wa值。 该值是等待IO完成所花费的时间。
这是一个众所周知的，充分讨论的事实，当谈到IO时，EBS卷performance不佳。 这就是为什么许多组织会通过RAID（通常是RAID 0，但可能还有其他一些层次也可能有用）将几个EBS卷绑在一起来提高性能。