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（默认设置）时，每次触发save操作时，redis都将进行分叉，默认情况下，每15分钟设置为一次。当执行更多写入Redis的操作时，RDB写入频率为每 60秒一次。
• 每个fork都会使用“copy-on-write”内存分配，这意味着虽然内存实际上不会加倍 - 但它会出现在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在进行后台保存时会分叉进程，但只会在保存进行时复制正在更改的内存。因此，CPU /内存的增加在很大程度上取决于保存运行时有多少数据被更改。所以它有时肯定会是一个巨大的峰值，而其他时间的峰值可能会小得多（或根本没有，取决于你的负载看起来如何）。

Answer 3

文档说： ＆＃34; Redis AOF逐步更新现有状态，如MySQL或MongoDB，而RDB快照一次又一次地创建所有内容，这在概念上更加强大。＆＃34;

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