memcached的大key存储与slab钙化问题踩坑

这篇具有很好参考价值的文章主要介绍了memcached的大key存储与slab钙化问题踩坑。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

线上启用memcached(以下简称mc)作为热点缓存组件已经多年,其稳定性和性能都经历住了考验,这里记录一下踩过的几个坑。

大key存储

某年某月某日,观察mysql的读库CPU占比有些异常偏高,去check慢查询log,发现部分应有缓存的慢sql居然存在几秒执行一次情况,不符合缓存数小时的代码逻辑。
查看业务log在每次查询sql之后也确实有将结果set至mc之中:

# python代码
mc.set(cache_key, v, 3600)

而set返回的取值却是False而非正常的True,很快想到mc著名的只可存储不超过1MB大小的key限制,在以往的业务场景中没有出现过这么大的key,所以一直没达到过这个限制,直到这一次撞上。
要解决超过1MB大小的key存储问题有以下几个思路:

  1. 想办法将cache结果变小
  2. 换个cache组件
  3. mc >=1.4.2 版本其实已经支持命令行参数-I指定最大key大小了,线上使用版本支持最小1KB最大128MB的设置
  4. 将大key拆分为几个子key,通过set_multi和get_multi实现统一的读写。

无论是通过2或3都可以支持更大的key存储,但是更大的key存储对于读写传输其实都更不友好,而思路4需要手动拆分、组装子key略显麻烦,所以优先从思路1着手,意外发现python使用的memcached库其实提供了key压缩功能,在写入时指定min_compress_len参数即可:

mc.set(key, v, time=expires, min_compress_len=1024)

如上表示写入的v对象序列化大小若>=1024则启用压缩存储,库底层会将其压缩后再写入mc,读取时库底层也会自动解压缩后再返回,业务层可以说完全无感,并且压缩后还能极大降低存储和传输成本。
最终通过min_compress_len参数启用大key压缩后,原1MB大小的key直瘦身了4/5。

slab钙化

启用大key压缩后mc度过了好一段岁月静好的日子,直到某一天...

大规模key分布变动导致的钙化

查看zabbix上的相关监控,发现mc的key查询miss比例居然接近50%!这个缓存命中率着实让人深思,进一步check后发现同时异常的指标还有evicted items数,日常取值居然可以达到数百/S的级别。
mc官方文档对evicted items的定义如下:

evicted                Number of times an item had to be evicted from the LRU before it expired.

即存储的key在其实际过期前被从LRU强制清理了,这一般说明mc剩余可分配内存不足了,所以新key写入时只能先从LRU淘汰一部分key腾出空间后再给新key使用,但是查看mc的内存使用率,明明还有超过>2GB的剩余内存可用。
最终调查后真相大白:mc明明剩余大量内存可用,写入新key却不断导致旧key被提前清除的现象其实是mc特有的slab钙化问题所致:

Memcached采用LRU(Least Recent Used)淘汰算法,在内存容量满时踢出过期失效和LRU数据,为新数据腾出内存空间。不过该淘汰算法在内存空间不足以分配新的Slab情况下,这时只会在同一类Slab内部踢出数据。即当某个Slab容量满,且不能在内存足够分配新的Slab,只会在相同Slab内部踢出数据,而不会挪用或者踢出其他Slab的数据。这种局部剔除数据的淘汰算法带来一个问题:Slab钙化。

简单来说memcached 使用的不同尺寸slab一旦分配完成就不可变了,所以如果某类slab已用尽,即便其他slab剩余大量空闲内存也无法再对其加以利用。
业务这边之前对使用mc的部分缓存key进行了整合优化,在优化之前单mc的全部5GB内存均已根据key存储情况分配给了特定的slab,而优化之后大大降低了小key的数量,取而代之的是相对更紧凑的大key,key的数量和大小分布都发生了显著的变化,于是原有的适用于大量小key的slab分配就无法满足优化后的key存储了。
最终体现为,中等大小的slab内存已被耗尽,每次写入新key只能先通过LRU淘汰部分旧key腾出空间,体现为evicted数异常偏高,并且直接影响了缓存命中率,而小尺寸的slab却长期大量空闲,体现为mc内存使用剩余空间一直充足。
网上检索解决钙化问题有三个办法:

1) 重启Memcached实例,简单粗暴,启动后重新分配Slab class,但是如果是单点可能造成大量请求访问数据库,出现雪崩现象,冲跨数据库。
2) 随机过期:过期淘汰策略也支持淘汰其他slab class的数据,twitter工程师采用随机选择一个Slab,释放该Slab的所有缓存数据,然后重新建立一个合适的Slab。
3) 通过slab_reassign、slab_authmove参数控制。

方法2看上去应是twitter的定制版mc Twemcache的特有功能,方法3则是线上mc已支持的方案,但首次接触也不敢贸然直接在线上使用。
考虑到mc仅作为热点缓存其数据可丢失,且部署有多台分摊压力,直接采用低峰时段分别重启单个mc的策略解决,重启后evicted item直接降为0,cache命中率升至90%上下。

少量大key变动导致的钙化

首次钙化之后又是一段岁月静好,直到...
某段时间开始一个主要接口偶发耗时会突然飙升一下,对应机器的CPU使用也会瞬间飚高一小阵,查看zabbix监控时,发现mc的 evicted items>0已持续好一段时间,但一直是个位数/S的级别,看着影响不大。
进一步执行stats items命令,发现发生key evict的是最大的chunk_size=1048576 的slab 42,这也就是说存在大小在512KB~1MB之间的大key,同时当前mc分配的1MB slab个数已无法满足其存储,也无法再分配出新的1MB大小的slab,最终体现为对于大key的再次钙化。
由于slab钙化大key会被频繁evict,对应缓存机制基本失效,所幸server端针对该类大key的读取还做了一个短期的本地cache,避免了每次请求都穿透到db。
在某些特定时刻,当mc中对应大key失效且本地cache失效,对应请求又较多的时候,多个独立的请求都会穿透到db获取数据,而后再写入mc,无论是穿透到db获取数据后本地进行相应的数据组装处理逻辑,还是读写mc的压缩、解压缩数据操作,都比较耗CPU,最终会体现为api耗时增加,且CPU使用率也存在飚高的现象。
近期并没有涉及大key读写的改动,那这次的大key slab钙化又是怎么来的?进一步探查原因:触发evict的大key近期确实无相关逻辑改动,但该部分旧key的大小和运营放出的资源多少直接相关,近一段时间放出的资源一直持续增加,旧key原本大小是<512KB,所以使用的是512KB的slab 41,近期持续增大为>512KB后,就只能使用1MB的slab 42存储了,对于slab 42来说相当于在原有支持的大key数量基础上又新的大key存储需要支持,又由于slab钙化无法再分配新的slab 42,最终触发evict,cache命中率降低,api偶发耗时上升。
最终解决方案:还是在业务低峰期逐个重启mc,触发slab重分配即可。

总结

memcached作为一个开源的纯内存kv缓存组件,上手简单、性能、稳定性都有足够保证,但是实际使用时也不可掉以轻心,对其相关监控与关注不能少,对于其特有的最大key存储限制、slab钙化问题要有一定的认识并能及时处理。
转载请注明出处,原文地址:https://www.cnblogs.com/AcAc-t/p/memcached_large_key_slab_calcification.html

参考

https://github.com/memcached/memcached/blob/master/doc/protocol.txt#L637
https://github.com/memcached/memcached/wiki/ReleaseNotes142#configurable-maximum-item-size
https://www.jianshu.com/p/b91a45711460
https://blog.twitter.com/engineering/en_us/a/2012/caching-with-twemcache
https://www.cnblogs.com/AcAc-t/p/memcached_large_key_slab_calcification.html
https://bugwz.com/2020/05/24/memcached-slab-calcification/#2-2-2、Rebalance执行逻辑
https://www.cnblogs.com/Leo_wl/p/3310294.html文章来源地址https://www.toymoban.com/news/detail-501367.html

到了这里,关于memcached的大key存储与slab钙化问题踩坑的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 纵然是在产业互联网的时代业已来临的大背景下,人们对于它的认识依然是短浅的

    纵然是在产业互联网的时代业已来临的大背景下,人们对于它的认识依然是短浅的。这样一种认识的最为直接的结果,便是我们看到了各式各样的产业互联网平台的出现。 如果一定要找到这些互联网平台的特点的话,以产业端为出发点,无疑是它的最大的特点之一。很显然,

    2023年04月21日
    浏览(48)
  • 在云原生时代,构建高效的大数据存储与分析平台

    🎈个人主页:程序员 小侯 🎐CSDN新晋作者 🎉欢迎 👍点赞✍评论⭐收藏 ✨收录专栏:大数据系列 ✨文章内容:大数据存储 🤝希望作者的文章能对你有所帮助,有不足的地方请在评论区留言指正,大家一起学习交流!🤗 在云原生时代,构建高效的大数据存储与分析平台需

    2024年02月10日
    浏览(40)
  • NoSQL 数据库管理工具,搭载强大支持:Redis、Memcached、SSDB、LevelDB、RocksDB,为您的数据存储提供无与伦比的灵活性与性能!

    【官网地址】:http://www.redisant.cn/nosql 直观的用户界面 从单一应用程序中同时连接 Redis、Memcached、SSDB、LevelDB、RocksDB,你可以快速轻松地创建、管理和维护数据库。 简洁的数据操作 快速搜索、编辑、删除、创建键;支持丰富的数据类型,包括:JSON、XML、HEX、MsgPack、YAML、整

    2024年02月21日
    浏览(41)
  • Mysql以key-val存储、正常存储的区别

    你作为一个服务端工程师,假设产品要求设计这么一个页面,页面上包含很多模块,每个模块都可以单独进行变更,有些模块是富文本。 实现方式有很多,我们来聊比较常用的两种,看看mysql的表如何设计。 第一种使用key-val的方案,这就需要两张表。 第二种方式则是放在一

    2024年02月07日
    浏览(35)
  • 学习笔记MinIo对象存储-Docker分布式集群搭建踩坑!

    ​ MinIO 是一款基于Go语言的高性能对象存储服务,在Github上已有39K+Star。它采用了Apache License v2.0开源协议,非常适合于存储大容量非结构化的数据,例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等。 本文将使用 MinIO 来自建一个对象存储服务用于存储图片。 ​ M

    2024年02月11日
    浏览(53)
  • Minio 踩坑 Docker 使用 免费开源对象存储 MINIO 包会安装

    minio简介: 对象存储人工智能数据基础设施 MinIO 是一种高性能、S3 兼容的对象存储。它是为大规模 AI/ML、数据湖和数据库工作负载。它是软件定义的并在任何云或本地基础设施上运行。MinIO 具有双重许可根据开源 GNU AGPL v3 和商业企业许可证。 之前使用的是官方的minio/minio,

    2024年04月14日
    浏览(46)
  • 50个最受欢迎的大数据面试问题

    大数据时代才刚刚开始。随着越来越多的公司倾向于大数据来运营他们的业务,对人才的需求空前高涨。这对您意味着什么?如果您想在任何大数据岗位上工作,它只会转化为更好的机会。您可以选择成为数据分析师,数据科学家,数据库管理员,大数据工程师,Hadoop大数据

    2023年04月14日
    浏览(40)
  • 关于vue学习过程中遇到的大问题!!4/19

    近期不参加面试了:针对问题  就去解决问题。不要发现问题了,不去解决 就空焦虑 (1)针对vue相当于没有系统学过这件事:需要重新花时间补习 【最全最新Vue、Vuejs教程,从入门到精通】 https://www.bilibili.com/video/BV15741177Eh/?p=101share_source=copy_webvd_source=011d4ea3d9ec16c7445c65e3d8

    2023年04月19日
    浏览(30)
  • 如何优化因为高亮造成的大文本(大字段)检索缓慢问题

    首先还是说一下背景,工作中用到了 elasticsearch 的检索以及高亮展示,但是索引中的 content 字段是读取的大文本内容,所以后果就是索引的单个字段很大,造成单独检索请求的时候速度还可以,但是加入高亮之后检索请求的耗时就非常的慢了。所以本文从 更换高亮器类型 的

    2024年02月11日
    浏览(36)
  • 智能建筑中的大数据分析:概述,应用,安全和隐私问题

    作者:禅与计算机程序设计艺术 近年来,智能建筑、智慧城市等新兴的概念层出不穷,人们对智能建筑、智慧城市追求的是从根本上解决环境问题、提升社会生活品质、实现经济社会效益的目标。智能建筑可谓是国际化进程中最具代表性的新兴产业领域之一。智能建筑即“未

    2024年02月15日
    浏览(40)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包