我收到了一位 Redis 用户的报告，我不知道该如何回复，因为我不是 Linux 及其调度程序领域的专家，但是我们（作为 Redis 项目）需要解决这类问题，尤其是将来，因为使用 Redis Cluster，我们将在一个盒子里同时运行许多 Redis 实例。所以我在这里寻求帮助。
问题：
- 内核：“Linux redis1 2.6.32-305-ec2 #9-Ubuntu SMP 星期四 4 月 15 日 08:05:38 UTC 2010 x86_64 GNU/Linux”
- 有足够的可用 RAM，没有其他进程进行大量 I/O。
- 重要的，运行在 EC2 大实例上，而不是真正的服务器上。我从未在非虚拟化环境中看到过这样的事情。EC2 实例是：“高内存超大型实例 17.1 GB 内存、6.5 ECU（2 个虚拟核心，每个核心有 3.25 个 EC2 计算单元）、420 GB 本地实例存储、64 位平台”。
基本上，一旦您重新启动大型 Redis 实例，系统就会变得非常慢，您无法再在 shell 上输入内容。当 Redis 加载实例时，它会使用 100% 的 CPU（它会尽可能快地加载数据）并顺序读取 dump.rdb 文件。I/O 不是特别高，因为加载是 CPU 密集型的，而不是 I/O 密集型的。
为什么一个拥有两个 CPU 和大量 RAM、磁盘上没有交换内容的机器在承受这种工作负载时基本上会停止工作？
我觉得这和它是 EC2 实例有很大关系，所以和使用的虚拟化技术有关，因为我每次都会加载 Redis24 GB 数据集在我的盒子里没有任何问题（即使其他 Redis 实例以高负载运行）。
谢谢任何提示！
萨尔瓦托雷
编辑：添加一些我从 Twitter 收到的反馈：
来自@ezmobius：@antirez 首先要做的是从 /mnt 或本地临时驱动器尝试，看看它是否是 EBS 不稳定，其次是确保它不是“首次写入惩罚”（谷歌搜索），如果是，那么您需要先在磁盘上添加 0。
来自 @dvirsky：@antirez 我在这样的 ec2 节点上运行了许多 redis 实例。我注意到 bgsave 的速度有所减慢，但没有发现这种现象。
答案1
“top” 的输出可能会提供一些线索。左上角附近有一个字段，标记为“% stealing”，它反映了转移到同一物理盒上的其他客户机的硬件 CPU 数量。当虚拟机管理程序决定将更多 CPU 分配给另一个客户机时，我见过这种类型的减速，尤其是当我执行一些长时间运行的 CPU 密集型任务时。
不确定这是否是你的问题但值得检查。
答案2
我在 EC2 实例上也遇到过同样的问题。这可能与 Redis 无关 - 它会在发生大量 IO 时发生（例如，当 redis 加载转储文件时）。
看看亚马逊论坛上的这个帖子：https://forums.aws.amazon.com/thread.jspa?messageID=215406
我已经尝试了不同的内核/图像，现在它运行良好（在旧的 2.6.21 内核上）。
答案3
您应该检查 CPU 窃取（xx.x%st在 CPU 线的右侧），它会top在您遇到 100% 负载和冻结 shell 时显示。窃取表示虚拟机管理程序从您的机器窃取了多少实际 CPU 周期并将其提供给另一台机器。CPU 窃取仅在虚拟化环境中相关。我在微型实例上遇到了同样的问题，如果执行 CPU 密集型任务，这基本上会使我的实例大约 1 小时左右无法使用（直到我的任务完成）。
您可以通过阅读找到有关此主题的更多信息这篇关于 Greg's Ramblings 的文章。不过，如果你相信 Greg 的话，这应该只会发生在微型实例上。