Cloud Memorystore Redis CPU 利用率高

Question

我们正在使用 Cloud Memorystore Redis 实例向我们面向互联网的关键任务应用程序添加缓存层。对 Memorystore 实例的调用总数（包括 get、set 和 key expiry 操作）约为每秒 10-15K。CPU 利用率一直在 75-80% 左右，并且预计利用率会更高。

目前，我们在标准服务层下使用 M4 容量层。

https://cloud.google.com/memorystore/docs/redis/pricing

需要澄清以下几点。

1. M4容量层对应多少个CPU核心？
2. CPU 利用率超过 100% 真的很令人震惊吗？我们预计会出现任何明显的性能问题吗？
3. 有哪些选项可以解决由较高 CPU 利用率 (>=100%) 引起的性能问题（如果有）？切换到 M5 容量层将解决高 CPU 消耗和相应问题。

我们的应用程序确实是 CPU 密集型的，并且我们看不到任何进一步优化我们的应用程序的方法。期待一些有用的参考。

Answer 1

解决您的问题。

1. M4容量层对应多少个CPU核心？
Cloud Memorystore for Redis 是一项由 Google 管理的服务，这意味着 Google 可以保留运行 Redis 服务的虚拟机的内部详细信息（资源）。尽管如此，容量层越高，虚拟机拥有的资源（CPU）就越多。特别是对于您的情况，添加 CPU 并不能解决 CPU 使用问题，因为 redis 服务本身是单线程的。

从前面的链接可以看到：

为了最大限度地提高 CPU 使用率，您可以启动多个 Redis 实例。
如果您想使用多个 CPU，您可以尽早开始考虑某种方式进行分片。

2. CPU 利用率超过 100% 真的令人震惊吗？
是的，CPU 利用率高是令人担忧的，因为它可能导致连接错误或高延迟。CPU 利用率很重要，而且 Redis 实例是否足够高效以在给定延迟下维持吞吐量也很重要。redis-cli --latency当 CPU % 较高时，您可以使用该命令检查 redis 延迟。

3. 我们预计会出现任何明显的性能问题吗？
这确实很难说或预测，因为它取决于几个因素（客户端服务、在时间范围内运行的命令、工作负载）。高延迟和性能问题的一些最常见原因是：

• 客户端虚拟机或服务过载并且无法使用来自 Redis 的消息：当客户端打开到 Redis 的 TCP 连接时，Redis 服务器将有一个消息缓冲区发送到该连接。如果客户端服务的 CPU 已满，内核没有时间从 Redis 接收消息，那么 Redis 服务器上的消息就会被填满。

• 执行的命令消耗大量 CPU：已知以下命令的处理成本可能非常昂贵：
  EVAL/EVALSHA
  KEYS
  LRANGE
  ZRANGE/ZREVRANGE

4.-有哪些选项可以解决由较高 CPU 利用率 (>=100%) 引起的性能问题（如果有）？
这个问题主要围绕您的实现的扩展设计。由于 Redis 是单线程的，因此降低 CPU 百分比的更好方法是将数据分片到多个 Redis 实例中，并在其前面设置一个代理来分配负载。请查看Twemproxy此链接部分下的图表。

5.-切换到M5容量层是否可以解决高CPU消耗和相应问题？
切换到更高的容量层应该可以暂时缓解延迟，但这称为垂直扩展，仅限于 Cloud Memorystore 提供的层。