redis内存和cpu峰值

Question

我们在我们的应用程序中使用 redis 来处理一些数据，这非常棒。但是我注意到redis-server 进程偶尔会出现 CPU 和内存峰值。

这是来自我们的生产和暂存环境的Giraffe dashboard。分期显然不那么忙，但生产通常也不是很忙......

这似乎与后台保存相关，但并非全部相关。只有少数人创造了这个尖峰。也许所有人都可以，但这仅取决于测量分辨率（有些根本没有被我们的内存/cpu监控周期捕获）。我不完全确定。

我仍然想知道这是否是预期/正常的。我们没有观察到任何问题，但我想安全起见。如果我们的生产有更多的流量/活动，我们是否可能会看到更多这样的峰值？

更新：

峰值时的redis日志文件

[18588] 05 May 11:42:51.004 * 10 changes in 300 seconds. Saving...
[18588] 05 May 11:42:51.258 * Background saving started by pid 32712
[32712] 05 May 11:43:00.511 * DB saved on disk
[32712] 05 May 11:43:00.549 * RDB: 1 MB of memory used by copy-on-write
[18588] 05 May 11:43:00.629 * Background saving terminated with success

Answer 1

通过进一步试验和阅读redis persistence，我认为可以得出以下观察结果：

• 使用 RDB（默认设置）时，redis 将在每次触发 save 操作时分叉，该操作（默认情况下）设置为每 15 分钟一次至少。当对 Redis 执行更多写入时，RDB 写入频率会达到每 60 秒一次。
• 每个 fork 都将使用“写入时复制”内存分配，这意味着虽然内存实际上不会翻倍 - 它会在 ps、htop 等工具上出现。
• fork 本身可能是一个 CPU 密集型操作，particularly on xen-based virtual hosts（这是我们目前使用的）。
• 写操作似乎完全覆盖现有的 RDB 文件。它不只写入更改，而是将整个数据集转储到磁盘。

因此，在具有 4Gb RAM 和大约 750Mb 数据集的适度虚拟主机上（在我发布问题时），这开始变得相当“昂贵”。我们观察到这些 CPU/内存峰值，以及增加的 IO，即使在相当中等的负载/redis 使用情况下也是如此。

所以回答我自己的问题 - 这似乎是“预期”的行为。

为了改善这种情况，我们选择将配置切换为使用 RDB 和 AOF 的组合。 AOF（仅附加文件）似乎只将更改写入磁盘。您仍然可以（并且应该）将 AOF 文件配置为重写（使用 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 设置）。还建议仍将 RDB 用于快照。但是，在这种配置中，您可能可以不那么频繁地进行完全重写/快照，并且仍然保持相当好的性能和更好的持久性。

Answer 2

文档说： “Redis AOF 以增量方式更新现有状态，就像 MySQL 或 MongoDB 一样，而 RDB 快照一次又一次地从头开始创建所有内容，这在概念上更加稳健。”

来源：http://redis.io/topics/persistence（在 AOF 的劣势中）

Answer 3

如果我没记错的话，redis 在进行后台保存时会分叉该进程，但只会在保存过程中复制正在更改的内存。因此，CPU/内存的增加很大程度上取决于保存运行时更改了多少数据。因此，它有时肯定会是一个巨大的峰值，而其他时候的峰值则要小得多（或者根本没有，这取决于您的负载情况）。