Redis 内存和 CPU 峰值

Question

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

这是 Giraffe dashboard来 self 们的生产和登台环境。分期显然没有那么忙，但生产也不是很忙......

这似乎与后台保存相关，但并非全部相关。只有少数人创造了这个峰值。也许都可以，但这只是取决于测量分辨率(有些根本没有在我们的内存/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 操作时 fork ，(默认情况下)设置为每 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 进行快照。然而，在这种配置中，您可能可以降低完全重写/快照的频率，并仍然保持相当不错的性能和更好的耐用性。