redis内存和cpu尖峰

我们在我们的应用中使用redis作为一些数据，它非常棒。我注意到redis-server进程中偶尔会出现cpu和内存峰值。redis内存和cpu尖峰

Process and memory monitoring on our Giraffe dashboard

这是从我们的生产和暂存环境Giraffe dashboard。舞台显然不那么繁忙，但生产不是很忙，要么通常...

这似乎与后台保存相关，但与所有这些都不相关。只有少数人创造了这个高峰。也许都行，但这只是测量分辨率的问题（有些根本不在我们的内存/ CPU监控周期中）。我不完全确定。

我还在想这是否是预期的/正常的。我们没有观察到任何问题，但我想保持安全。如果我们的生产有更多的流量/活动，我们是否会看到更多像这样的尖峰？

UPDATE：

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

来源

2013-05-05 gingerlime

从这个进一步的实验和阅读redis persistence，我认为以下意见可以提出：

当使用RDB（默认设置），Redis的将每一个save操作被触发时叉，这（默认情况下）设置为每15分钟至少。当执行更多对Redis的写入操作时，RDB写入频率为每60秒。
每个分支将使用“写入时复制”内存分配，这意味着虽然内存不会实际增加两倍，但它会出现在类似ps,htop等工具上。
分叉本身可以是一个相当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进行快照。然而，在这种配置中，你可能不太经常做完整的重写/快照，并且仍然保持非常好的性能和更好的耐久性。

来源

2013-07-07 17:00:36 gingerlime