我们正在使用 Cloud Memorystore Redis 实例为我们面向互联网的关键任务应用程序添加一个缓存层。对 Memorystore 实例的调用总数(包括获取、设置和 key 过期操作)约为每秒 10-15K。 CPU 利用率一直保持在 75-80% 左右,预计利用率会更高。
目前,我们在标准服务层级下使用 M4 容量层级。
https://cloud.google.com/memorystore/docs/redis/pricing
需要澄清以下几点。
- M4容量层对应多少个CPU核心?
- CPU 使用率超过 100% 真的很可怕吗?我们预计会出现任何明显的性能问题吗?
- 解决由较高 CPU 使用率 (>=100%) 引起的性能问题(如果有)有哪些选择?切换到 M5 容量层是否会解决高 CPU 消耗和相应问题。
我们的应用程序确实是 CPU 密集型的,我们看不到任何进一步优化我们的应用程序的方法。期待一些有用的引用。
最佳答案
解决您的问题。
<强>1。 M4容量层对应多少个CPU核心?
Cloud Memorystore for Redis 是谷歌管理的服务,这意味着谷歌可以保留运行 redis 服务的虚拟机的内部细节(资源)。仍然预计容量层越高,虚拟机将拥有的资源(CPU)越多。特别是对于您的情况,添加 CPU 不会解决有关 CPU 使用率的问题,因为 redis 服务本身是 single threaded .
从前面的链接可以看出:
To maximize CPU usage you can start multiple instances of Redis.
If you want to use multiple CPUs you can start thinking of some way to shard earlier.
<强>2。 CPU 使用率超过 100% 真的很可怕吗?
是的,高 CPU 使用率令人担忧,因为它会导致连接错误或高延迟。
CPU 利用率很重要,但 Redis 实例是否足够高效以在给定延迟下维持吞吐量也很重要。当 CPU % 很高时,您可以使用命令 redis-cli --latency
检查 redis 延迟。
<强>3。我们预计会出现任何明显的性能问题吗?
这真的很难说或预测,因为它取决于几个因素(客户端服务、在时间范围内运行的命令、工作负载)。导致高延迟和性能问题的一些最常见原因是:
客户端 VM 或服务过载且未使用来自 Redis 的消息:当客户端打开到 redis 的 TCP 连接时,redis 服务器有一个消息缓冲区要发送到该连接.如果客户端服务的 CPU 已用尽,内核没有时间接收来自 Redis 的消息,那么它们就会填满 Redis 服务器。
执行的命令消耗大量 CPU:已知以下命令的处理成本可能非常高:
评估/评估
key
范围
ZRANGE/ZREVRANGE
4.- 有哪些选项可以解决由较高 CPU 利用率 (>=100%) 引起的性能问题(如果有)?
这个问题主要围绕您的实现的缩放设计。由于 Redis 是单线程的,因此降低 CPU 百分比的更好方法是将数据分片到多个 Redis 实例中,并在其前面设置一个代理来分配负载。请查看来自此 link 的 Twemproxy
部分下的图表.
5.-切换到 M5 容量层是否会解决高 CPU 消耗和相应问题?
切换到更高容量层应该有助于暂时缓解延迟,但这被称为垂直扩展,仅限于 Cloud Memorystore 提供的层。
关于google-cloud-platform - Cloud Memorystore Redis 高 CPU 使用率,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66534066/