zoukankan      html  css  js  c++  java
  • 内存溢出分析定位

    内存溢出:

    • 堆内存溢出

    堆内存中存在大量对象,这些对象都有被引用,当所有对象占用空间达到堆内存的最大值,
    就会出现内存溢出OutOfMemory:Java heap space

    • 永久代溢出 -- (解决方案:加大永久代内存)

    类的一些信息,如类名、访问修饰符、字段描述、方法描述等,所占空间大于永久代最大
    值,就会出现OutOfMemoryError:PermGen space

    内存溢出的检测方法

    1、Jdk/bin目录下有很多检测工具
    • 图形界面:
      – Jconsole
      – Jvisualvm(也可以监控线程)
    • 命令行工具
      –Jstat –gcutil pid 1000 100 查看GC情况
      -Jmap –histo pid | head -20 查看当前jvm中占用内存最大的20个类
      -Jmap –heap pid

    FullGC频率:建议单次FullGC时间<200ms,超出则存在优化空间

    2、现象
    2.1 垃圾回收和CPU使用率

    image

    1、两条曲线的走势完美吻合,每一次GC,CPU使用率都会升高,请求响应时间变长
    2、有时候CPU使用率波动特别大,有可能正在进行 GC
    3、响应时间波动特别大、TPS波动也特别大,系统有可能在进行 GC,需要排查

    2.2 内存泄漏和TPS

    image

    1、TPS开始有波动,然后波动越来越大,最后陡降至0

    内存溢出实战

    怎么排查:

    • 1、观察现象:tps先是出现大幅波动,后慢慢降低。甚至将为0,响应时间随之波动,慢慢升高
    • 2、通过 jstat -gcutil pid 1000 100命令可以观察到 Jvm中的Old区不断增加,FGC(FullGC)非常频繁,对应FGCT(FullGC需要的时间)消耗的时间也不短增加
    • 3、通过 jconsole/jvisualvm 可以看到,堆内存曲线不断上升,接近上线时,变成一条直线,就算压测结束很久后,内存仍然降不下来
    • 3、日志报错 java.lang.OutOfMemoryError:Java heap space
    • 4、通过 Jmap –histo pid | head -20 查看当前jvm堆内存中实例数和占用内存最多的前20个对象或类
    • 5、也可以通过jvisualvm,进行远程堆dump,然后把dump文件下载下来,用jvisualvm打开进行分析,可以看到更直观的jvm中对象的信息

    查看Jvm运行状态的命令

    监控jvm的GC情况
    jstat -gcutil pid 1000 100

    查看jvm配置信息
    jmap -heap pid:可以看到java进程的堆的配置信息,各区的空间大小和配置信息

    查看jvm中类和对象的占用情况
    jmap -histo 5279 | head -20:查看jvm中各个类的实例数、占用内存数量以及类的全名

    堆文件dump
    jmap -dump:format=b,file=m.hdump 17777:对堆内存进行dump,以文件的形式进行保存下来,可以用jvisualvm等工具对文件进行分析

    内存泄露应用场景

    在什么样的场景下监控内存泄露问题?

    • 1、在试压阶段,或任意场景都可以考虑通过jvisualvm和jstat监控jvm的情况
    • 2、在稳定性场景中,一定要关注Jvm内存使用的情况,在长时间的压测下,最容易看出内存泄露的问题

    JVM常见参数

    -Xms2048m:初始堆大小,建议<物理内存的1/4,默认值为物理内存的1/64
    -Xmx2048m:最大堆大小,建议与-Xms保持一致,默认值为物理内存的1/4
    -Xmn512m:新生代大小,建议不超过堆内存的1/2
    -Xss256k,线程堆栈大小,建议512-1024k
    -XX:PermSize=256m:永久代初始值,默认值为物理内存的1/64
    -XX:MaxPermSize=256m:永久代最大值,默认值为物理内存的1/4
    -XX:SurvivorRatio=8:年轻带中Eden区和Survivor区的比例,默认为8:1,即Eden(8),From
    Space(1),ToSpace(1)
    -XX:MaxTenuringThreshold=15:晋升到老年代的对象年龄,每个对象坚持过一次MinorGC后对象年龄+1,默认值是15,年龄超过15进入到老年代,该参数在串行GC时有效-
    XX:PretenureSizeThreshold=3145728:单位字节,只对Serial和ParNew两款收集器有效,新生代采用Parallel Scavenge GC时无效,大于这个值的对象直接在老年代进行分配

    CMS相关参数

    -XX:+UseConcMarkSweepGC:默认关闭,ParNew+CMS+Serial Old,当CMS收集器出现
    ConcurrentModeFailure错误(Jvm预留空间不足以容纳程序使用),采用后备收集器Serial Old
    -XX:CMSInitiatingOccupancyFraction=80:CMS收集器在老年代空间被使用多少时触发FullGC,默认为92
    -XX:+UseCMSCompactAtFullCollection:CMS收集器在FullGC时开启内存碎片的压缩,默认关闭
    -XX:CMSFullGCsBeforeCompaction=8:执行多少次不压缩FullGC后,进行一次压缩,默认是0(代表每次FullGC都进行压缩)
    -XX:+UseCMSInitiatingOccupancyOnly:使用手动定义初始化定义开始,禁止hostspot自行触发CMS GC
    -XX:ParallelGCThreads=8:并行收集器的线程数,此值最好配置与处理器数目相等 同样适用于CMS

    日志参数:

    -XX:+HeapDumpOnOutOfMemoryError:当发生内存溢出时,进行堆内存dump-XX:+PrintGCDetails:打印GC的详细信息

    企业实际测试环境配置

    -server -Xms1028m -Xmx1028m -XX:PermSize=256m -XX:MaxPermSize=256m -Xmn512m
    -XX:MaxDirectMemorySize=1g -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC
    -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000
    -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80
    -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=8
    -Xloggc:/home/admin/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
    -XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/home/admin/logs/java.hprof

  • 相关阅读:
    py计算程序运行时间-简易版
    py-冒泡排序
    py_冒泡排序
    Python测试函数运行时间
    py_二分查找
    Python发送get、post请求
    py_递归实例:汉诺塔问题
    递归实例:汉诺塔问题
    Jmeter断言实例—响应断言
    第十四天-linux命令及基础知识实战
  • 原文地址:https://www.cnblogs.com/DeryKong/p/15620028.html
Copyright © 2011-2022 走看看