【问题标题】：Cloud Memorystore Redis high CPU utilisationCloud Memorystore Redis CPU利用率高
【发布时间】：2021-03-08 17:04:38
【问题描述】：
我们正在使用 Cloud Memorystore Redis 实例向我们面向互联网的关键任务应用程序添加一个缓存层。对 Memorystore 实例的调用总数（包括获取、设置和密钥过期操作）约为每秒 10-15K。 CPU 利用率一直在 75-80% 左右，预计利用率会更高。
目前，我们在标准服务层下使用 M4 容量层。
https://cloud.google.com/memorystore/docs/redis/pricing
需要明确以下几点。
- M4 容量层对应多少个 CPU 内核？
- CPU 利用率超过 100% 真的很可怕吗？我们预计会有任何明显的性能问题吗？
- 有哪些选项可以解决由较高 CPU 利用率 (>=100%) 引起的性能问题（如果有）？切换到 M5 容量层将解决高 CPU 消耗和相应的问题。
我们的应用程序确实是 CPU 密集型的，我们看不到任何进一步优化我们的应用程序的方法。期待一些有用的参考资料。
【问题讨论】：
标签：
google-cloud-platform
redis
google-cloud-memorystore
【解决方案1】：
解决您的问题。
1. M4容量层对应多少个CPU核心？
Cloud Memorystore for Redis 是 Google 管理的服务，这意味着 Google 可以保留运行 redis 服务的虚拟机的内部详细信息（资源）。仍然预计容量层越高，虚拟机将拥有的资源（CPU）越多。特别是对于您的情况，添加 CPU 不会解决 CPU 使用率问题，因为 redis 服务本身是 single threaded。
从上一个链接可以看出：
要最大化 CPU 使用率，您可以启动多个 Redis 实例。
如果你想使用多个 CPU，你可以提前考虑一些分片的方法。
2。 CPU 利用率超过 100% 真的很可怕吗？
是的，CPU 使用率高是令人担忧的，因为它可能导致连接错误或高延迟。
CPU 利用率很重要，但 Redis 实例是否足够高效以在给定延迟下维持您的吞吐量也很重要。您可以在 CPU % 较高时使用命令 redis-cli --latency 检查 redis 延迟。
3。我们预计会有任何明显的性能问题吗？
这真的很难说或预测，因为它取决于几个因素（客户端服务、在时间范围内运行的命令、工作负载）。导致高延迟和性能问题的一些最常见原因是：
-
客户端虚拟机或服务超载并且不使用来自 Redis 的消息：当客户端打开到 redis 的 TCP 连接时，redis 服务器有一个消息缓冲区要发送到该连接。如果客户端服务的 CPU 已用尽，内核没有时间接收来自 redis 的消息，那么它们就会在 redis 服务器上填满。
-
执行的命令会消耗大量 CPU：已知以下命令的处理成本可能非常高：
EVAL/EVALSHA
钥匙
朗格
ZRANGE/ZREVRANGE
4.-有哪些选项可以解决由较高 CPU 利用率 (>=100%) 引起的性能问题（如果有）？
这个问题主要围绕您的实现的扩展设计。由于 redis 是单线程的，因此降低 CPU 百分比的更好方法是将数据分片到多个 redis 实例中，并在其前面有一个代理来分配负载。请查看此link 中的Twemproxy 部分下的图表。
5.-切换到 M5 容量层会解决高 CPU 消耗和相应的问题吗？
切换到更高容量的层应该有助于暂时缓解延迟，但这称为垂直扩展，仅限于 Cloud Memorystore 提供的层。