• java进程占用系统内存高,排查解决


    故障:今天许多开发反馈测试平台卡,访问不了,第一感觉判断是服务器内存爆了,或者cpu占用过高,上服务器看了一下,确实是内存爆了。然后开始定位问题原因,因为阿里这边安全的原因,具体的图片就不方便上传了,拿网上的图来说

    1. 使用top命令查看系统资源的使用情况,命令:top

      blob.png

      如图可以看到java的进程内存使用率较高,java进程的内存使用率达到了70%+

    2.定位线程问题(通过命令查看9718进程的线程情况),命令:ps p 9718 -L -o pcpu,pmem,pid,tid,time,tname,cmd

      blob.png

      

     由此可以看到这PID:9718的进程产生了很多线程。接下来就可以通过jstack查看内存使用的堆栈。

    3. 查看内存使用的堆栈:在这里我们挑选了TID=9731的线程进行分析,首先需要将9731这个id转换为16进制。需输入如下命令,

     printf "%x " 9731

     

    blob.png

     接下需要使用16进制的2603

    4. 将PID为9718的堆栈信息打印到jstack.log中,命令:jstack -l 9718 > jstack.log

     

       blob.png

     

    5. 查看堆栈信息文件,命令:vim jstack.log

     

       在进行搜索TID为2603的相关信息。如图:

       

       blob.png

       可以看到这个线程状态为:WAITING。通过查看文件分析 看到大量 Java Thread State。

       说明它在等待另一个条件的发生,来把自己唤醒,或者干脆它是调用了 sleep(N)。

       此时线程状态大致为以下几种:

       java.lang.Thread.State: WAITING (parking):一直等那个条件发生;

       java.lang.Thread.State: TIMED_WAITING (parking或sleeping):定时的,那个条件不到来,也将定时唤醒自己。

    6.代码优化:将文件发送给开发。优化下线程

    这里还有一种排查思路

    在定位到具体的PID后,可以到处进程快照,看看这个线程做了啥

    jstack -l 9718 > ./9718.stack
    

      

    再用grep查看下线程在文件里做了啥

    cat 9718.stack |grep '2603' -C 8
    

      

    这里随便定位一个,基本上这样查都可以定位到线程的问题

  • 相关阅读:
    100以内质数的算法
    WebAPI和WebService的区别
    .net core 2.0 数据访问-迁移
    .net core 2.0 Redis的基本使用
    .net core 2.0 Autofac
    net core 2.0 + Autofac的坑
    MVC路由机制
    MVC原理
    CentOS安装GIt、上传项目到git仓库
    ARM 汇编指令集 特点5:ARM 多级指令流水线
  • 原文地址:https://www.cnblogs.com/hkgov/p/13448711.html
Copyright © 2020-2023  润新知