我们有一个 m1.medium EC2 实例，带有一个小型 (15G) EBS 驱动器，同时运行 Rails 3 和 PostgreSQL 服务器。我们注意到 CPU 有时会出现峰值，最后意识到即使是简单、持续的 EBS 访问似乎也会占用 CPU。例如，仅 grep 大约 3G 的日志就会导致 100% 的 CPU 使用率 - 这意味着两个核心，这对于 grep 来说是不可能的！删除一堆日志文件也会占用大约 25% 的 CPU，这比我预期的要多。我们不交换。
这是正常的吗？很难用 Google 搜索到这个，因为“高 CPU”也是一种 EC2 实例的名称。我很乐意提供更多详细信息和基准，但首先我想检查一下这是否是真的。
答案1
EBS 卷的性能可能受到以下因素的影响：
新的 EBS 卷具有首次使用惩罚，即使它们是从 EBS 快照创建的。第一次读取或写入卷上的每个块所花的时间将比后续的命中时间长得多。
启动 EBS 快照后，当您尝试写入尚未复制到 S3 快照存储的块时，EBS 卷可能会遇到高 iowait。
EBS 卷使用实例上的网络带宽。如果升级到更大的实例类型，您可能会获得更好的 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
答案2
您提到的 grep 期间所花费的几乎所有 CPU 时间都可能是由于 iowait。在 grep 期间在另一个终端中运行 top 并观察值%wa。该值是等待 IO 完成所花费的时间。
众所周知，EBS 卷在 IO 方面表现不佳。这就是为什么许多组织会通过 RAID（通常是 RAID 0，但其他级别也可能有用）将多个 EBS 卷绑定在一起以提高性能。