我如何解决 ElastiCache for Redis 中的高延迟问题?

2 分钟阅读
0

我想解决 Amazon ElastiCache for Redis 中的高延迟问题。

简短描述

以下是 ElastiCache for Redis 中出现高延迟问题的常见原因:

  • 命令速度慢
  • 内存使用率高导致交换活动增加
  • 网络问题
  • 客户端延迟问题
  • Redis 同步
  • ElastiCache 集群事件

解决方法

根据以下原因对您的高延迟问题进行故障排除:

命令速度慢

Redis 是单线程的。因此,当请求处理的速度较慢时,其他客户端必须等待。这种减速会导致处理请求的总时间增加。要监视各类命令的平均延迟,使用适用于 Redis 的 Amazon CloudWatch 指标。此外,常见的 Redis 操作以微秒延迟计算。CloudWatch 指标每分钟采样一次,延迟指标显示为多个命令的聚合。单个命令可能会导致意外结果,如超时,但不会有指标图表中出现的重大变化。要检索需要较长时间完成的命令列表,使用 SLOWLOG GET。同时,在 redis-cli 中运行 slowlog get 128 命令。有关更多信息,请参阅 Redis 网站上的 SLOWLOG GET。另请参阅我如何在 ElastiCache for Redis 缓存集群中启用 Redis 慢日志?

如果 EngineCPUUtilization 指标有所增加,请参阅我如何解决 ElastiCache for Redis 自行设计集群中 CPU 使用率增加的问题?

以下是复杂命令的示例:

  • 生产环境中对大型数据集执行的 KEYS。KEYS 会搜寻整个键空间,搜索指定模式。有关更多信息,请参阅 Redis 网站上的 KEYS
  • 需要较长时间来运行的 Lua 脚本。有关更多信息,请参阅 Redis 网站上的使用 Lua 编写脚本

内存使用率高导致交换活动增加

当集群的内存压力增加时,Redis 会更换内存页面。这可能会导致延迟增加和超时,因为内存页会转入并从更换区域转出。以下各项表明 CloudWatch 指标中的更换活动在增加:

  • SwapUsage 增加
  • FreeableMemory 非常低
  • BytesUsedForCacheDatabaseMemoryUsagePercentage 指标较高

要解决更换活动增加的问题,请参阅以下资源:

网络问题

要解决由网络问题引起的高延迟问题,请参见以下场景:

客户端与 ElastiCache 集群之间的网络延迟
要隔离客户端与集群节点之间的网络延迟,请参阅如何对 VPC 中的 EC2 Linux 或 Windows 实例与本地主机之间通过互联网网关通信时的网络性能问题进行故障排除?

集群达到网络限制
ElastiCache 节点与相关的 Amazon Elastic Compute Cloud (Amazon EC2) 实例共用相同的网络限制。例如,cache.m6g.large 节点类型与 m6g.large Amazon EC2 实例的网络限制相同。有关对 ElastiCache 节点网络限制进行故障排除的信息,请参阅网络相关限制。另外,最佳做法是监视 Amazon EC2 实例的网络性能,并检查您的带宽能力、每秒数据包 (PPS) 性能和跟踪的连接。

TCP/SSL 握手延迟

客户端使用 TCP 连接来连接到 Redis 集群。创建 TCP 连接可能需要几毫秒时间。此延迟可能会导致应用程序的 Redis 操作产生额外开销。而且,ElastiCache 节点在 CPU 上会收到额外压力。确保控制新连接的数量,尤其是当您的集群使用 ElastiCache 传输中加密 (TLS) 功能时。大量被打开 (NewConnections) 和关闭的连接可能会影响节点的性能。对于有大量连接的情况,使用连接池将已建立的 TCP 连接缓存到池中。要实现连接池,使用您的 Redis 客户端库(如果支持),或手动构建连接池。您还可以使用聚合命令作为优化技巧,如 MSET/MGET 或 Redis 管道。有关更多信息,请参阅 Redis 网站上的 Redis 管道

ElastiCache 节点上有大量连接

最佳做法是跟踪 CurrConnectionsNewConnections CloudWatch 指标。这些指标监视 Redis 接受的 TCP 连接的数量。大量的 TCP 连接可能会导致耗尽 65,000 maxclients 限制。此限制是每个节点可以有的最大并发连接数。有关更多信息,请参阅 Redis 网站上的最大并发连接客户端数。当您达到 65,000 限制时,将出现 ERR max number of clients reached 错误。如果添加的连接超过 Linux 服务器限制或跟踪的最大连接数,会发生连接超时。有关如何防止出现大量连接的更多信息,请参阅 Redis 客户端最佳实践

客户端延迟问题

要确定客户端资源是否导致延迟问题,检查客户端的内存、CPU 和网络利用率。确保这些资源未接近限制。如果您的应用程序在 Amazon EC2 实例上运行,可以使用 CloudWatch 指标来发现问题。此外,在 Amazon EC2 实例内使用监视工具,如 atopCloudWatch 代理

如果在应用程序上设置的超时配置值太小,您可能会收到不必要的超时错误。要解决这些错误,配置客户端超时,让服务器有足够的时间处理请求和生成响应。有关更多信息,请参阅 Redis 客户端最佳实践。另外,超时错误会显示其他信息。请务必查看超时错误的详细信息,找出您的延迟的原因。检查以下模式,确定延迟是由客户端、ElastiCache 节点还是网络引起的:

  • 检查超时是频繁发生还是在一天中的特定时间发生。
  • 检查超时是发生在某个特定客户端还是多个客户端上。
  • 检查超时是发生在某个特定 Redis 节点还是多个节点上。
  • 检查超时是发生在某个特定集群还是多个集群上。

Redis 同步

Redis 同步在备份、节点更换和扩展事件时开始。这是一种计算密集型工作负载,可能会导致延迟。要检查同步是否正在进行,使用 SaveInProgress CloudWatch 指标。有关更多信息,请参阅如何实现同步和备份

ElastiCache 集群事件

要检查延迟发生的时间段,请查看 ElastiCache 控制台中的事件部分。检查后台活动,如可能由 ElastiCache 托管的维护和服务更新引起的节点更换或失效转移事件。另外,检查是否发生意外的硬件失败。计划事件通知通过 AWS Health Dashboard 和电子邮件接收。

事件日志示例:

Finished recovery for cache nodes 0001Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed

相关信息

使用 Amazon CloudWatch 监视 Amazon ElastiCache for Redis 的最佳做法

其他故障排除步骤 https://kcs.support.aws.dev/article/elasticache-redis-correct-high-latency/2

AWS 官方
AWS 官方已更新 8 个月前