JVM_性能调优_面试_数据库连接池配置
2021-12-11 13:25:42 3 举报ddd
作者其他创作
大纲/内容
一般来说年轻代的参数设置合理，老年代CMS的参数设置基本可以默认
阶段2: 线上排查
方法 :将年轻代Xmn调大点 或 将eden和s01的比例调节一下使得S区容量大一点
复制算法用在年轻代span style=\"font-size: inherit;\
根据对象动态年龄判断
通过jmap 找到频繁增长的不会被释放的大对象所对应的代码
先根据订单业务估算出每个请求大概会产生多大对象
统计 QPS 和 请求响应时间的平均值，以此计算 minIdle，并设置 initialSize = minIdle
Q-PS = 并发量 / 平均响应时间 （每秒查询次数）
按照这个标准即 \
年轻代的对象什么时候会移动到老年代
查哪些大对象被占导致这个问题
一般mindorgc 几分钟或几十分钟做一次都正常的fullgc 几小时或几天几周做一次 都正常
jmap -histo pid | head -20
因为这个不会一次回收所有对象，这样边回收边让系统去运行
例子: 每天300w PV 的在单台机器上，这台机器需要多少Q-PS？ pv:页面浏览次数( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (Q-PS
什么是QPS? 每秒查询
利用jstack找出占用cpu高得堆栈信息：用top命令找出java进程的内存情况，然后用jstack pid得到线程堆栈即可以得到运行的代码行 查看代码是否需要优化
主要根据堆内存的几个分配机制 找出不合理的地方并进行jvm参数重置
什么时候可以用G1
假设一个请求为5ms，那么这个qps即一个连接每秒可以处理200个请求。假如要支持2000个并发，那就需10个连接
日均百万级订单(JVM调优)
xmx和xms堆内存最大最小设置的一样就是为了减少内存抖动
根据对象存活性质
JVM优化就是减少full gc
JVM调优排查步骤
一般上线前，压测情况下可以用图形界面来查看JVM的情况
用jstat 命令 先统计看下运行一段时间 执行了多少次younggc 和full gc：比如n天里面发生500次 fullgc，共耗时200秒，发生YoungGC 耗时1万多次 共花费500秒
例如电商(订单服务)
通过GC日志可以看出JVM的运行状况
数据库连接池如何配置
先根据业务获取哪个业务会产生最大的内存对像，该内存对象是多大比如订单业务 根据订单类估算一条订单多大 再扩大30倍，因为可能一条订单请求会涉及到其它的对象
根据不同的业务来进行不同的参数分配
优化yc和fc的次数(从参数模型到代码优化的整个过程)
JVM参数配置
通常情况下，大部分对象都是朝生夕死，持久对象一般是以下几种: 一些Spring的bean，连接池等
根据该结果来设置JVM的参数模型
使用arthas查找内存溢出问题
选择合适的垃圾收集器
然后再用jmap(命令)/jvisualM(可视化工具)找出大对象
如果不满意 可以继续调优结合对象的分配机制去思考，哪些情况下年轻代往老年代移动对象，并对其优化
如果系统不是你开发的 是别人的 怎么来调优
maxActive
20:00
阶段3: 解决问题
遇到问题如何排查
一般20，30分钟做一次Full-gc还好
原理：每天80%的访问集中在20%的时间里，这20%时间叫 做峰值时间。公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(Q-PS)
大对象直接进入老年代
根据大对象性质:
我碰到的问题并解决
优化点(3个机制)
直接给定一些默认的参数或不给参数先跑起来
所以可以给cms加个参数UseCMSCompactAtFullColleciton=5即做5次fullgc后做碎片整理
代码问题引起的内存泄漏
指定mixedgc的停顿时间可以提升用户体验
出了问题如何排查
jstat -gc pid 查出的指标可以得知
JVM参数如何合理的设置
内存泄漏导致内存溢出
阶段1:开发完后初步调试
原因找到了，接下来去查程序的bug到底在哪里产生
通过jstat来可以查看到younggc和fullgc次数
CMS基于标记-整理算法适用在老年代()，因为老年代的 存活对象比较多，所以 如果用复制算法（先将存活对象搬到一块区，再做清理）效率低
一般脑子里要有个jvm的内存模型
希望达到的目的就是 让大部分对象在年轻代就被干掉，从而减少进入老年代导致产生full gc
首先根据业务需求去估算某次请求会发生的最大的对象
注意 这里s0和s1不能设置过小 why? 因为根据\"对象动态年龄判断\"机制，如果eden区的垃圾对象加起来超过s0的一半空间，那么就会直接移动到老年代 2:01:20
JVM调优应该分两块
连接池的的连接都被用着，在来的话就只能先等着，等多久就是maxWait
通过日志
如果经常有这种现象存在: 50%以上堆被存活对象使用
minIdle最小连接数推荐 5
dump文件通常只有系统出现OOM的时候，服务器挂了才去查看
非电商业务
这个gc日志是通过java命令行加个 -xx:log得到的结果
订单对象大小是根据订单类里的字段大小来估算的
结合业务系统情况分析每秒产生多大的对象，再根据这个来设计参数的调优模型
FGC和YGC的发生频率
根据不同的场景选取适当的垃圾回收器
优化点
就是做了fullgc 后 回收了才 1kb 甚至没回收
年轻代增长的速率
在survior区来来回回年龄达到15的
maxWait
推荐内网(网络状况好)800;网络状况不是特别好的情况下推荐大于等于 1200。
看下大对象是否多或者是否对象是否比较多
再执行几遍 发现CardInFo这个对象再一直增加
等系统运行了一段时间，通过jstat命令统计发生fullgc和younggc的次数
堆分配不合理
找到问题如何解决
收藏
收藏
0 条评论
下一页
