5

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

我们 Giraffe 仪表板上的进程和内存监控

这是我们的生产和登台环境中的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
4

3 回答 3

11

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

  • 使用 RDB 时（默认设置），redis 会在每次触发操作时分叉，（默认情况下）至少save设置为每 15 分钟一次。当对 Redis 执行更多写入时，RDB 写入频率会达到每60 秒一次。
  • 每个 fork 都将使用“写时复制”内存分配，这意味着虽然内存实际上不会翻倍 - 它会出现在诸如 之类的工具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 用于快照。然而，在这种配置中，您可能可以不那么频繁地进行完全重写/快照，并且仍然保持相当好的性能和更好的持久性。

于 2013-07-07T17:00:36.510 回答
1

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

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

于 2013-10-27T03:57:02.200 回答
0

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

于 2013-05-05T20:22:49.680 回答