网站设计公司哪家好如何选择呀,有些网站怎么经常换域名,wordpress注册页面在什么文件,东营最新公告今天作者#xff1a;看破
一、简单回顾
事故回溯总结一句话#xff1a;
#xff08;1#xff09;因为大 KEY 调用量#xff0c;随着白天自然流量趋势增长而增长#xff0c;最终在业务高峰最高点期占满带宽使用 100%。
#xfeff; #xfeff;
#xff08;2#xff… 作者看破
一、简单回顾
事故回溯总结一句话
1因为大 KEY 调用量随着白天自然流量趋势增长而增长最终在业务高峰最高点期占满带宽使用 100%。 2从而引发 redis 的内存使用率在 5min 之内从 0%-100%。 3最终全面 GET SET timeout 崩溃11 点 22 分 02 秒。 4最终导致页面返回 timeout。
未解之谜
疑问点内存使用率 100% 就等同于 redis 不可用吗
解答正常使用情况下不是。 redis 有【缓存淘汰机制】Redis 在内存使用率达到 100% 时不会直接崩溃。相反它依赖内存淘汰策略来释放内存确保系统的稳定性。 学习更多24 替换策略缓存满了怎么办
24 | 替换策略缓存满了怎么办-Redis核心技术与实战-极客时间 这个配置在哪里 大部分同学都是不会主动去调整这里的参数的。 因此大概率默认的是volatile-lru 行为使用 LRULeast Recently Used最近最少使用算法驱逐键。volatile-lru 仅驱逐设有过期时间的键allkeys-lru 则驱逐所有键。 适用场景缓存场景不介意丢失一些数据。 确保你根据实际需求配置适当的内存淘汰策略以便在内存达到上限时系统能够稳定地处理新请求而不会出现写操作失败的情况只要不是 noeviction。 也就是说照理 SET GET 都应该没啥问题才对先不考虑其他复杂命令。 尽管 Redis 本身不会轻易崩溃但如果内存耗尽且没有淘汰策略或者淘汰策略未能生效Redis 可能拒绝新的写操作并返回错误OOM command not allowed when used memory maxmemory 如果系统的配置或者操作系统的内存管理不当可能会导致 Redis 进程被操作系统杀死。 疑问点但是事故现象就是内存使用率 100% 时redis 不可用怎么解释
猜测 1会是淘汰不及时导致的性能瓶颈吗 也就是说写入的速度淘汰的速度。 解答如果是正常的业务写入不可能 redis 纯内存淘汰速度是非常快的 这个业务特性也并非高频写入 这个 redis 实例其实里面存储的 KEY 很少最终占了整个实例的内存使用率5%。 不太符合正常使用下 KEY 不断增多最终挤爆内存使用率的问题。 因此初步结论Redis 的崩溃一般不会是由于单纯写入速度超过淘汰速度引起的尤其是使用了合理的内存淘汰策略时如果写入速度非常高而淘汰策略无法及时清除旧数据Redis 可能会非常频繁地进行键的查找和淘汰操作从而导致性能下降。 18 波动的响应延迟如何应对变慢的 Redis上
18 | 波动的响应延迟如何应对变慢的Redis上-Redis核心技术与实战-极客时间 具体机制如下 过期 key 的自动删除机制。它是 Redis 用来回收内存空间的常用机制应用广泛本身就会引起 Redis 操作阻塞导致性能变慢所以你必须要知道该机制对性能的影响。 Redis 键值对的 key 可以设置过期时间。默认情况下Redis 每 100 毫秒会删除一些过期 key具体的算法如下 1.采样
ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 个数的 key并将其中过期的 key 全部删除 2.如果超过 25% 的 key 过期了则重复删除的过程直到过期 key 的比例降至 25% 以下。 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 是 Redis 的一个参数默认是 20那么一秒内基本有 200 个过期 key 会被删除。这一策略对清除过期 key、释放内存空间很有帮助。如果每秒钟删除 200 个过期 key并不会对 Redis 造成太大影响。 但是如果触发了上面这个算法的第二条Redis 就会一直删除以释放内存空间。注意删除操作是阻塞的Redis 4.0 后可以用异步线程机制来减少阻塞影响。所以一旦该条件触发Redis 的线程就会一直执行删除这样一来就没办法正常服务其他的键值操作了就会进一步引起其他键值操作的延迟增加Redis 就会变慢。 那么算法的第二条是怎么被触发的呢其中一个重要来源就是频繁使用带有相同时间参数的 EXPIREAT 命令设置过期 key这就会导致在同一秒内有大量的 key 同时过期。 可以类比 JVM 频繁 GC 造成的性能影响。 猜测 2那就是写入太凶猛且是【非正常业务写入】 那到底是什么导致了内存使用率激增呢 蛛丝马迹
如何解决 Redis 内存使用率突然升高
https://help.aliyun.com/zh/redis/support/how-to-solve-the-sudden-increase-in-redis-memory-usage?spma2c4g.11186623.0.i12 因此查阅了资料发现最为贴近的答案。 证据支撑 真相大白 果然是这样说明内存是被【缓冲区】挤爆的。 21 缓冲区一个可能引发“惨案”的地方
21 | 缓冲区一个可能引发“惨案”的地方-Redis核心技术与实战-极客时间 知识点Redis 的内存占用组成 使用 info memory 进行分析我随便模拟了一个缓冲区溢出的 case并非事故现场因为当时不会。
# Memoryused_memory:1072693248used_memory_human:1023.99Mused_memory_rss:1090519040used_memory_rss_human:1.02Gused_memory_peak:1072693248used_memory_peak_human:1023.99Mused_memory_peak_perc:100.00%used_memory_overhead:1048576000used_memory_startup:1024000used_memory_dataset:23929848used_memory_dataset_perc:2.23%allocator_allocated:1072693248allocator_active:1090519040allocator_resident:1090519040total_system_memory:16777216000total_system_memory_human:16.00Gused_memory_lua:37888used_memory_lua_human:37.89Kused_memory_scripts:1024000used_memory_scripts_human:1.00Mmaxmemory:1073741824maxmemory_human:1.00Gmaxmemory_policy:noevictionallocator_frag_ratio:1.02allocator_frag_bytes:17825792allocator_rss_ratio:1.00allocator_rss_bytes:0rss_overhead_ratio:1.00rss_overhead_bytes:0mem_fragmentation_ratio:1.02mem_fragmentation_bytes:17825792mem_not_counted_for_evict:0mem_replication_backlog:0mem_clients_slaves:0mem_clients_normal:1048576000mem_aof_buffer:0mem_allocator:jemalloc-5.1.0active_defrag_running:0lazyfree_pending_objects:0:1072693248used_memory_human:1023.99Mused_memory_rss:1090519040used_memory_rss_human:1.02Gused_memory_peak:1072693248used_memory_peak_human:1023.99Mused_memory_peak_perc:100.00%used_memory_overhead:1048576000used_memory_startup:1024000used_memory_dataset:23929848used_memory_dataset_perc:2.23%allocator_allocated:1072693248allocator_active:1090519040allocator_resident:1090519040total_system_memory:16777216000total_system_memory_human:16.00Gused_memory_lua:37888used_memory_lua_human:37.89Kused_memory_scripts:1024000used_memory_scripts_human:1.00Mmaxmemory:1073741824maxmemory_human:1.00Gmaxmemory_policy:noevictionallocator_frag_ratio:1.02allocator_frag_bytes:17825792allocator_rss_ratio:1.00allocator_rss_bytes:0rss_overhead_ratio:1.00rss_overhead_bytes:0mem_fragmentation_ratio:1.02mem_fragmentation_bytes:17825792mem_not_counted_for_evict:0mem_replication_backlog:0mem_clients_slaves:0mem_clients_normal:1048576000mem_aof_buffer:0mem_allocator:jemalloc-5.1.0active_defrag_running:0lazyfree_pending_objects:0 分析和解释
从上面的 INFO memory 输出中我们可以看到一些关键信息这些信息表明大部分内存被缓冲区占用殆尽 1.内存使用情况 used_memory: 1072693248 1.02 GB maxmemory: 1073741824 1.00 GB
上面的输出表明当前内存使用几乎达到了配置的最大内存限制内存已接近耗尽。 2.缓冲区占用 used_memory_overhead: 1048576000 1.00 GB
这个值表示 Redis 开销的内存包括缓冲区、连接和其他元数据。在这种情况下大部分 used_memory (1.02 GB) 被 used_memory_overhead (1.00 GB) 占用这意味着大部分内存都被缓冲区等开销占据。 3.数据集占用 used_memory_dataset: 23929848 23.93 MB used_memory_dataset_perc: 2.23%
这里显示实际存储的数据只占了非常少的一部分内存约 23.93 MB而绝大部分内存被缓冲区占据。 4.客户端缓冲区 mem_clients_normal: 1048576000 1.00 GB
这表明普通客户端连接占用了约 1.00 GB 内存这通常意味着输出缓冲区可能已经接近或达到了设定的限制。 5.内存碎片 allocator_frag_ratio: 1.02 mem_fragmentation_ratio: 1.02
碎片率不高表明内存被合理使用但被缓冲区占用过多。 总结
从上面的例子可以看出Redis 的内存几乎被缓冲区占用殆尽。以下是具体的结论 当前内存使用 (used_memory) 已经接近最大内存限制 (maxmemory)即 1.02 GB 接近 1.00 GB 的限制。 内存开销 (used_memory_overhead) 很大主要被客户端普通连接使用可能是输出缓冲区而实际的数据仅占用了很少的内存。 分配器和 RSS 碎片率 (allocator_frag_ratio 和 mem_fragmentation_ratio) 较低表明碎片不是问题。 缓冲内存的理论最大值推导 为什么要有缓冲区 Redis 工作原理-单客户端视角简单版 Redis 工作原理-单客户端视角复杂版 缓冲区的功能其实很简单主要就是用一块内存空间来暂时存放命令数据以免出现因为数据和命令的处理速度慢于发送速度而导致的数据丢失和性能问题。 因此Redis 工作原理-多客户端视角简单版含缓冲区。 输入缓冲区 定义 内存占用 输出缓冲区 定义 内存占用 Redis Server 的输出大小通常是不可控制的。存在 bigkey 的时候就会产生体积庞大的返回数据。另外也有可能因为执行了太多命令导致产生返回数据的速率超过了往客户端发送的速率导致服务器堆积大量消息从而导致输出缓冲区越来越大占用过多内存甚至导致系统崩溃。Redis 通过设置 client-output-buffer-limit 来保护系统安全。 不出意外默认是32MB 8MB 60s 对于 Pub/Sub 连接: 硬限制每个 Pub/Sub 客户端连接的输出缓冲区最大可以达到 32MB 。 连接池最大连接数300 个连接其中所有连接假设都在处理 Pub/Sub 消息且达到了最大缓冲区限制。 故理论上最大输出缓冲区可以达到
最大输出缓冲区占用硬限制×连接池最大连接数最大输出缓冲区占用硬限制×连接池最大连接数32MB×3009600MB9.375GB 因此在这种配置下所有 Pub/Sub 连接的输出缓冲区理论上的最大占用内存为 9.375 GB。 因此在 client-output-buffer-limit 是默认的情况下最大占用内存为 9.375 GB。 所以MAX输出缓冲区输入缓冲区是否会造成内存使用率 100% 当然 MAX输出缓冲区输入缓冲区10.375GB 一个实例的内存规格在本 case 中是 2G 最后的效果就是 对象存储的部分因为是有过期时间的过期了自然被清理了。 【缓冲内存】↑ 涌入 【对象内存】↓ 定时清理 并受 MAX 内存掣肘上限 最终的结局Redis 的内存完全被缓冲区占据。 自然每当有 SET 请求进来的时候SET 不进来——因为「内存淘汰策略」(maxmemory-policy) 淘汰的是【对象内存】压根起不到作用 结论 Redis 的内存完全被缓冲区占据实际上 Redis 将无法正常工作包括数据存储SET 操作和数据读取GET 操作。
分析为何缓冲区激增Redis 不可用的时间点 11:22:02之前都发生了什么 知道了缓冲区挤爆 Redis 内存会导致 Redis 不工作之后接下来就是分析为何当时出现了缓冲区激增并最终导致 redis 不可用。
实例信息 相关代码 案件还原 1.自然增长导致流出带宽不断变大直至 96MB/s。 2.流出带宽超过 96MB/s输出缓冲区内存占用激增甚至溢出 300setMaxTotal*10 机器 ip 数量个客户端之前推导过可以到 9G。 3.导致输出缓冲区爆了redis 客户端连接不得不关闭。
4.客户端连接关闭后导致请求都走 DB。
5.DB 走完之后都会执行 SET。
6.SET 流量飙升且因都是大 KEY导致流入带宽激增别看写 QPS 只有 50但是如果每个写都是 2MB就可以做到瞬间占满流入带宽。 7.Redis 主线程模型处理请求的速度过慢大 KEY出现了间歇性阻塞无法及时处理正常发送的请求导致客户端发送的请求在输入缓冲区越积越多。
8.输入缓冲区内存随即激增。 9.最终redis 内存被缓冲区内存输入、输出完全侵占。
10.后续的 SET GET 命令甚至都进不了输入缓冲区阻塞持续到客户端配置的 SoTimeout 时间但是流入流出带宽依然占据并持续总带宽到达了 216MB/s 实例最大带宽 192MB/s。 11.造成最终的不可用后续的命令想进场要依赖当前输入缓冲区里的命令被执行给你腾出来位置但是还是那句话 Redis 主线程处理消化的速度实在是太慢了从图中可以看到 Redis 的 QPS 骤降。 11:35 分之后我把 redis 降级了全使用 db 来抗流量。 二、开发运维规范
可以看到 Redis 的性能是有边界的不能盲目相信所谓的高性能。
真正理解性能须使用 benchmark。 它也是有问题能造成他的性能瓶颈的。 在上述的事故中就占了【网络资源消耗高】【存储资源消耗高】两大问题。 因此也到了本文的方法论环节从业务部署、Key 的设计、SDK、命令、运维管理等维度展示云数据库 Redis 开发运维规范 业务部署规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis Key 设计规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis SDK 使用规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 命令使用规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 运维管理规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 业务部署规范 Key 设计规范 SDK 使用规范 命令使用规范 运维管理规范 三、重点行动项
大 KEY
大 KEY 其实并不是长度过长的 KEY而是存放了慢查询命令的 KEY。 对于 String 类型慢查询的本质在于 value 的大小。 对于其他类型慢查询的本质在于集合的大小时间复杂度带来。 如何找到大 key 阿里云发现并处理 Redis 的大 Key 和热 Key
https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys?spma2c4g.11186623.0.i1
如何解决大 key
其实就是一个字 拆。 1.对于字符串类型的 key我们通常要在业务层面将 value 的大小控制在 10KB 左右如果 value 确实很大可以考虑采用序列化算法和压缩算法来处理推荐常用的几种序列化算法:Protostuff、Kryo 或者 Fst。 2.对于集合类型的 key我们通常要通过控制集合内元素数量来避免 bigKey通常的做法是将一个大的集合类型的 key 拆分成若干小集合类型的 key 来达到目的。 压测关注点
1.数据是否倾斜不能只看聚合信息要切换到分片上看数据节点 2.是否有大 key、热 key
a.压测过程中关注1CloudDBA-实时 TOP KEY 统计2CloudDBA-慢请求
b.压测后1CloudDBA-离线全量 KEY 分析2CloudDBA-诊断报告做到分析报告时间覆盖压测时段 3.CPU 使用率、内存使用率、带宽使用率变化趋势流入、流出都要看最好看一个缓存周期 4.如果可以打开审计日志看写入日志是否符合代码逻辑。
常用运维命令
出线上事故的时候用于快速分析和保留现场。
CLIENT LIST info memory MEMORY USAGE
