redis内存和cpu峰值

Question

我们在我们的应用程序中使用redis来获取某些数据,这非常棒.我注意到这个redis-server过程偶尔会出现cpu和内存峰值.

这是我们的生产和登台环境中的Giraffe仪表板.分段显然不那么繁忙,但通常生产并不是非常繁忙......

这似乎与后台保存有关,但与所有这些都无关.只有极少数人创造了这种飙升.也许所有人都这样做了,但它只能达到测量分辨率(有些根本没有在我们的内存/ 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持久性,我认为可以做出以下观察:

• 使用RDB(默认设置)时,每次save触发操作时,redis都会分叉,默认情况下,每15分钟将其设置为一次.当执行更多写入Redis的操作时,RDB写入频率为每60秒一次.
• 每个叉将使用一个"写入时复制"的内存分配,这意味着,虽然内存不会真正双-它会出现等一样的工具ps,htop等等.
• fork本身可能是一个cpu密集型操作,特别是在基于xen的虚拟主机上(这是我们目前使用的).
• 写操作似乎完全覆盖了现有的RDB文件.它不会只写入更改,而是将整个数据集转储到磁盘.

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

所以回答我自己的问题 - 这似乎是"预期的"行为.

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