一次caffeine引起的CPU飙升问题

背景

背景是上游服务接入了博主团队提供的sdk，已经长达3年，运行稳定无异常，随着最近冲业绩，流量越来越大，直至某一天，其中一个接入方（流量很大）告知CPU在慢慢上升且没有回落的迹象，dump文件能看到缓存的holder占用4个G，那不用说了，责无旁贷

打开他们的内存监控，G1的老年代占用大概是这个样子

在这里插入图片描述

可以看到，老年代每次gc后使用量都在上升，说明每次能gc的内存越来越少，而cpu也是蹭蹭往上追，直至崩掉

原因

查看dump，能看到我们的缓存对象cacheHoler占用高达4g，其中cacehKey的数量更是高达900w！

首先是惊呆了，这个缓存当初设置的maximumSize可只有2w啊，这900w什么鬼！

caffeine介绍

官方是这么说的，一句话，目前最牛逼的本地java缓存库

	Caffeine 是一个高性能Java 缓存库，提供接近最佳的命中率

我们先弄清楚caffeine的原理，是不是使用姿势有问题？

官方的一个小demo

LoadingCache<Key, Graph> cache = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));

对比一下我们的适用方式

Caffeine.newBuilder().executor(executorService).refreshAfterWrite(12000, TimeUnit.SECONDS).expireAfterWrite(600, TimeUnit.SECONDS).maximumSize(20000).buildAsync(key -> {return callForDemo("demo");});

不同之处也就是我们用了异步的cache，定义了自己的线程池，指定了refreshAfterWrite参数为1200秒

好像姿势没什么问题？
这不咱也找到了官方的异步用法

AsyncLoadingCache<Key, Graph> cache = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES)// Either: Build with a synchronous computation that is wrapped as asynchronous .buildAsync(key -> createExpensiveGraph(key));// Or: Build with a asynchronous computation that returns a future.buildAsync((key, executor) -> createExpensiveGraphAsync(key, executor));

思考每个参数的含义

  1. maximumSize：指定缓存可以包含的最大条目数。请注意，缓存可能会在超过此限制之前逐出某个条目，或者在逐出时暂时超过阈值。当缓存大小增长到接近最大值时，缓存会逐出不太可能再次使用的条目。例如，缓存可能会逐出某个条目，因为它最近未使用或非常经常使用。
  2. expireAfterAccess：指定在条目创建、最近替换其值或最后一次读取条目后经过固定持续时间后，应自动从缓存中删除每个条目
  3. refreshAfterWrite：指定在创建条目或最近替换其值后经过固定持续时间后，活动条目就有资格进行自动刷新。当出现对条目的第一个过时请求时，将执行自动刷新。触发刷新的请求将进行异步调用，并立即返回旧值。

一个重要信息：maximumSize的缓存不会立即驱逐
那为题是不是就出现在这里？

多线程模拟

那我们用1k个线程模拟一下从maximumSize为20的缓存实例获取缓存

        for (int i = 0; i < 1000; i++) {int finalI = i;new Thread(() -> {UserCharacter uc = new UserCharacter();uc.setUid(finalI +"");uc.setStationId(finalI +"111");configHolder.getAbResultCache(uc, "demo").getAbResults();}).start();}//Thread.sleep(2000);configHolder.getStats();

public void getStats() {System.out.println( abResultCache.synchronous().asMap());}

第一次调用，多线程获取缓存后立即查看缓存中的快照map数量为1000，明显超过maximumSize定义的20

第二次调用，添加代码Thread.sleep(5000);查看缓存中的快照map数量为20，正好是maximumSize定义的20

第三次调用，添加代码Thread.sleep(2000);查看缓存中的快照map数量为100-300不等，说明大于20的缓存条目正在被驱逐

结论

caffeine的缓存驱逐速度在高并发情况下跟不上缓存添加速度，造成内存gc不下来

且旧的缓存会被超过maximumSize的新缓存驱逐，所以20000个缓存其实根本没起到缓存的作用，很快就会被新缓存驱逐，10个线程一直被抢着来进行缓存的添加和驱逐，这也是为什么CPU快要被干爆了

那要怎么优化呢？

驱逐策略

caffeine提供了三类驱逐策略

基于size或者weigh

// Evict based on the number of entries in the cache
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().maximumSize(10_000).build(key -> createExpensiveGraph(key));// Evict based on the number of vertices in the cache
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().maximumWeight(10_000).weigher((Key key, Graph graph) -> graph.vertices().size()).build(key -> createExpensiveGraph(key));

maximumSize：指定缓存可以包含的最大条目数。请注意，缓存可能会在超过此限制之前逐出某个条目，或者在逐出时暂时超过阈值。当缓存大小增长到接近最大值时，缓存会逐出不太可能再次使用的条目。例如，缓存可能会逐出某个条目，因为它最近未使用或非常经常使用

weigher：如果不同的服务器空间具有不同的“权重”——例如，如果您的服务器值具有不同的内存占用——您可以指定一个权重函数Caffeine.weigher(Weigher)和一个最大的服务器权重Caffeine.maximumWeight(long)

基于时间

// Evict based on a fixed expiration policy
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfterAccess(5, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));// Evict based on a varying expiration policy
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfter(new Expiry<Key, Graph>() {public long expireAfterCreate(Key key, Graph graph, long currentTime) {// Use wall clock time, rather than nanotime, if from an external resourcelong seconds = graph.creationDate().plusHours(5).minus(System.currentTimeMillis(), MILLIS).toEpochSecond();return TimeUnit.SECONDS.toNanos(seconds);}public long expireAfterUpdate(Key key, Graph graph, long currentTime, long currentDuration) {return currentDuration;}public long expireAfterRead(Key key, Graph graph,long currentTime, long currentDuration) {return currentDuration;}}).build(key -> createExpensiveGraph(key));

咖啡因提供了快速定时驱动方法：

expireAfterAccess:(long, TimeUnit):指定在条目创建、最近替换其值或最后一次读取条目后经过固定持续时间后，应自动从缓存中删除每个条目。所有缓存读写操作（Cache.asMap().put(K, V)和Cache.asMap().get(Object)）都会重置访问时间，但不会通过对 Cache#asMap 的集合视图的操作来重置访问时间。

expireAfterWrite：(long, TimeUnit):指定在创建条目或最近替换其值后经过固定持续时间后，活动条目就有资格进行自动刷新

expireAfter(Expiry):分别定义缓存创建、更新、读取多久后过期

Scheduler: Caffeine.scheduler(Scheduler)使用接口和方法指定调度线程，而不是依赖其他服务器活动来触发实例行维护。提供的调度器可能无法提供实时保证。该计划是尽最大努力的，并且不会对何时删除过期的条目做出任何硬性保证。

基于引用 weakKeys/weakValues/softValues

指定存储在缓存中的每个键或值都应包装在 {@link WeakReference} 中或{@link SoftReference} （默认情况下，使用强引用）。使用以上方法时，生成的缓存将使用标识 （{@code ==}） 比较来确定键的相等性

注意值value支持weakValues和softValues，而key只支持weakKeys

WeakReference：gc就会被回收
SoftReference：gc时如果没有足够的内存时会被回收，如何量化这个内存是否充足，点这里

以上驱逐策略官方建议优先采用maximumSize，除非你对WeakReference和SoftReference的适用相当熟悉并清楚由此产生的后果，不然不建议使用引用驱逐策略。

优化

回归本案例，高峰期我们的cacheHolder里面有900w个缓存实例，而maximumSize设置仅为20000，由于cacheKey是用户维度的，显然20000个key对一下c端服务来说太少了，但是调高maximumSize又会引起cacheHolderi自身占用过多内存，调高线程池的最大线程数又会对争抢正常业务的CPU资源

可能的优化方案有：

  1. 降低缓存kv的大小，比如缓存v的大小从1k降低到20byte
  2. 将缓存的过期时间从10分钟调整到1分钟，加速缓存淘汰速度
  3. 当前缓存获取属于IO密集型业务，可以适当调高线程池最大线程数，以便有更多线程资源被拿来进行缓存驱逐
  4. 使用专门的Scheduler，与put缓存的线程隔离，专门用来维护缓存的过期刷新等
  5. 碍于内存压力，考虑使用引用驱逐策略，在内存不足时优先GC缓存
  6. 如果以上方案都不适用，使用别的方案代替caffeine，比如本地内存、分布式缓存redis等等

参考：https://github.com/ben-manes/caffeine/wiki/Eviction

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/400781.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

2分钟搭建一个简单的WebSocket服务器

2分钟搭建一个简单的WebSocket服务器

你好同学&#xff0c;我是沐爸&#xff0c;欢迎点赞、收藏和关注。个人知乎 如何用2分钟在本地搭建一个简单的 WebSocket 服务器&#xff1f;其实使用 Node.js&#xff0c;加上一些流行的库&#xff0c;是很容易实现的。前端同学通过自己搭建 WebSocket 服务器&#xff0c;对于…
阅读更多...
百问网全志系列开发板音频ALSA配置步骤详解

百问网全志系列开发板音频ALSA配置步骤详解

8 ALSA 8.1 音频相关概念 ​ 音频信号是一种连续变化的模拟信号&#xff0c;但计算机只能处理和记录二进制的数字信号&#xff0c;由自然音源得到的音频信号必须经过一定的变换&#xff0c;成为数字音频信号之后&#xff0c;才能送到计算机中作进一步的处理。 ​ 数字音频系…
阅读更多...
系统重装简记

系统重装简记

写在文章开头 因为固态损毁而更换固态&#xff0c;所以需要进行系统重装&#xff0c;由于系统重装都是固定的繁琐的步骤&#xff0c;所以就以这篇文章来记录一下系统重装的一些日常步骤&#xff0c;希望对你有帮助。 Hi&#xff0c;我是 sharkChili &#xff0c;是个不断在硬核…
阅读更多...
《Linux运维总结：基于x86_64架构CPU使用docker-compose一键离线部署etcd 3.5.15容器版分布式集群》

《Linux运维总结：基于x86_64架构CPU使用docker-compose一键离线部署etcd 3.5.15容器版分布式集群》

总结&#xff1a;整理不易&#xff0c;如果对你有帮助&#xff0c;可否点赞关注一下&#xff1f; 更多详细内容请参考&#xff1a;《Linux运维篇&#xff1a;Linux系统运维指南》 一、部署背景 由于业务系统的特殊性&#xff0c;我们需要面对不同的客户部署业务系统&#xff0…
阅读更多...
【网编】——UDP编程

【网编】——UDP编程

宏观操作 服务器&#xff1a;socket创套接字—bind绑定连接—recvfrom接收数据/sendto发送数据 客户端&#xff1a;socket创套接字—sendto发送数/recvfrom接收数据—close关闭套接字 函数 recv ssize_t recvfrom ( int sockfd , void * buf , size_t len , int flags , str…
阅读更多...
链接Mysql 报错connection errors； unblock with ‘mysqladmin flush-hosts‘错误的解决方法！亲测有效！

链接Mysql 报错connection errors； unblock with ‘mysqladmin flush-hosts‘错误的解决方法！亲测有效！

文章目录 前言一、使用 mysqladmin flush-hosts 命令解锁 IP 地址二、增加 max_connect_errors 参数三、检查连接错误的原因 前言 今天正常的对各大的测试服进行重启的时候发现每台服务器都启动失败&#xff01;查看日志发现每台服务器都报一下的错误 java.sql.SQLException:…
阅读更多...
【学习笔记】Day 13

【学习笔记】Day 13

一、进度概述 1、《地震勘探原理》第六章 二、详情 个人感觉第五&#xff0c;六&#xff0c;八章的解释更倾向于地质学那边负责的&#xff0c;但是多了解相关原理&#xff0c;肯定是有利于 DL-FWI 的相关研究的&#xff0c;所以这里只是做一个粗略的归纳&#xff0c;相关内容详…
阅读更多...
android车载手机互联投屏新专题-实战作业布置

android车载手机互联投屏新专题-实战作业布置

背景&#xff1a; 学习了马哥的投屏实战开发课程后&#xff0c;大家都可以实现如下图一样的手机车机多端互联的投屏场景。 即已经实现了手机和车机投屏互动&#xff0c;车机上手机画面屏幕可以与手机实体屏幕一样就是常见的Mirror模式&#xff0c;如果不一样就是课程里面讲的扩…
阅读更多...
【策略模式】设计模式系列：在Java中实现灵活的行为选择(实战指南)

【策略模式】设计模式系列：在Java中实现灵活的行为选择(实战指南)

文章目录 策略模式&#xff1a;在Java中实现灵活的行为选择引言1. 策略模式的组成1.1 抽象策略 (Strategy)1.2 具体策略 (Concrete Strategy)1.3 上下文 (Context)1.4 UML类图和时序图 2. 策略模式在Java中的实现步骤一&#xff1a;定义抽象策略接口步骤二&#xff1a;创建具体…
阅读更多...
波涛汹涌的海面：适用于恶劣环境的水冷电阻器

波涛汹涌的海面：适用于恶劣环境的水冷电阻器

电阻器液体冷却可提升 3.3kV 中压负载&#xff0c;并大幅减少工业和船舶应用中的电阻器占用空间。在起重机、升降机、升降机和输送机等电机驱动应用中&#xff0c;风冷电阻器很常见&#xff0c;但在中压、高功率应用中&#xff0c;液体冷却胜出。 使用 3.3kV 电源运行以转动 5…
阅读更多...
vue前端可以完整的显示编辑子级部门，用户管理可以为用户分配角色和部门？

vue前端可以完整的显示编辑子级部门，用户管理可以为用户分配角色和部门？

用户和角色是一对多的关系用户和部门是多对多得关系<template><div class="s"><!-- 操作按钮 --><div class="shang"><el-input v-model="searchText" placeholder="请输入搜索关键词" style="width:…
阅读更多...
MySQL的InnoDB的页里面存了些什么 --InnoDB存储梳理(三)

MySQL的InnoDB的页里面存了些什么 --InnoDB存储梳理(三)

文章目录 创建新表页的信息新增一条数据根据页号找数据信息脚本代码py_innodb_page_info根据地址计算页号根据页号计算起始地址 主要介绍表空间索引页里面有哪些内容&#xff0c;数据在表空间文件里面是怎么组织的 创建新表页的信息 CREATE TABLE test8 (id bigint(20) NOT N…
阅读更多...
跟着iMeta学做图｜ggplot2绘制多个饼图展示菌群物种组成

跟着iMeta学做图｜ggplot2绘制多个饼图展示菌群物种组成

原始教程链接&#xff1a;https://github.com/iMetaScience/iMetaPlot/tree/main/221017multi-pieplot 写在前面 饼图 (Pie Plot) 在微生物组研究中可以用来展示菌群物种组成&#xff0c;可以起到与堆叠柱状图相同的展示效果。本期我们挑选2022年4月5日刊登在iMeta上的The imp…
阅读更多...
服务器安装哪吒面板详细教程

服务器安装哪吒面板详细教程

本文长期更新地址&#xff1a; 服务器安装哪吒面板详细教程-星零岁的博客https://blog.0xwl.com/13568.html 注&#xff1a;本文中部分内容源自网络&#xff0c;第四步中部分来自本人曾经文章&#xff1a;云服务器安装配置宝塔面板并安装基础运行环境教程-星零岁的博客 今天来讲…
阅读更多...
VGMShield：揭秘视频生成模型滥用的检测与追踪技术

VGMShield：揭秘视频生成模型滥用的检测与追踪技术

人工智能咨询培训老师叶梓 转载标明出处 视频生成模型&#xff0c;如 Stable Video Diffusion 和 Videocrafter&#xff0c;已经能够生成合理且高分辨率的视频。但这些技术进步也带来了被恶意利用的风险&#xff0c;比如用于制造假新闻或进行政治宣传。因此&#xff0c;来自弗…
阅读更多...
前端学习大纲 | 主流前端技术 | 学习路线

前端学习大纲 | 主流前端技术 | 学习路线

需要完整的学习路线的宝子可以点击获取&#xff1a;点击即可获取完整的学习路线 第一阶段&#xff08;页面还原能力&#xff09; HTML5、CSS3、Git 第二阶段&#xff08;专攻 JS 逻辑能力&#xff09; JavaScript 基础、JavaScript 进阶、JavaScript 高级、ES6 第三阶段&a…
阅读更多...
Leetcode面试经典150题-125.验证回文串

Leetcode面试经典150题-125.验证回文串

解法都在代码里&#xff0c;不懂就留言或者私信 class Solution {/**这题目感觉不是算法题&#xff0c;应该是考coding的细节点&#xff0c;比如如何判断两个字符是否equals&#xff08;大小写要equals&#xff09;空格要忽略&#xff0c;感觉就是纯coding&#xff0c;难道是为…
阅读更多...
城市信息模型：构建未来智慧城市之基底座

城市信息模型：构建未来智慧城市之基底座

在智慧城市的宏大叙事中&#xff0c;城市信息模型&#xff08;City Information Model, CIM&#xff09;平台如同城市智能的神经中枢&#xff0c;将数据、空间与技术深度融合&#xff0c;为城市规划、管理、服务、居民生活提供了前所未有的洞察与优化途径。CIM平台的构建不仅是…
阅读更多...
【鸿蒙学习】HarmonyOS应用开发者基础 - 构建更加丰富的页面之Tabs（三）

【鸿蒙学习】HarmonyOS应用开发者基础 - 构建更加丰富的页面之Tabs（三）

学完时间&#xff1a;2024年8月14日 一、前言叨叨 学习HarmonyOS的第六课&#xff0c;人数又成功的降了500名左右&#xff0c;到了3575人了。 本文接上一文章【鸿蒙学习】HarmonyOS应用开发者基础 - 构建更加丰富的页面&#xff08;一&#xff09;&#xff0c;继续记录构建更…
阅读更多...
微信小程序预览PDF、H5预览PDF、网页预览PDF，并添加专属文字水印

微信小程序预览PDF、H5预览PDF、网页预览PDF，并添加专属文字水印

下载PDF.js 点击PDF.js下载地址 引入预览PDF 文件 // const url new URL("./1.pdf", import.meta.url).href // 在本地项目获取pdf // const url "https://xxxx/05d833041f.pdf" // 在线上链接获取pdf const url query.get(url) // 在地址栏获取pdf c…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023