• 分析系统变慢或卡死


    一、问题现象描述

    常见的反馈问题说法:web应用好慢呀,好像死了.

    这种问题描述不够清晰,慢有多种慢的现象,“死也不是一个专业的说法。下面我们将对这类问题进行分类说明,不同的死”法,慢法有不同的分析方式。

    基本要求:熟悉 Linux 基本操作、 Java 编程、 JDK 基本命令 Tong Web 使用,后面我们会用到。

    二“死”的问题

    死通常是对进程没了或是进程在但没反应而进行的描述。实际是进程崩溃、假死、产生僵尸进程这三类情况,其主要原因有以下几点:

    1最低级的“死”法(1)有人偷偷停了 Web应用,别的运维人员不知道。(2)把系统慢当成了“死, 其实还在运行,只是慢的跟”死一样,其实还没死,误报

    (3) TongWeb 不是以 nohup / startserver sh &或 startservemohup sh 后台方式启动,造成 ssh 或 telnet 断开后, TongWeb 进程停止.

    (4)应用代码里有 System . exit (0)代码,危险代码。这是退进程的,会导致整个 TongWeb 进程退出,从日志中可以明显看如下日志:

    [2016-01-1310:50.56] SEVERE [ web - container ][ The web applicauon l tuan ]still processing a request that has yet to finish . This is very likely to create a memory leak . 

    这种问题两种解决办法选其一

     A 找出应用代码用 System exit 的地方并删掉:

     B . startserver 启动脚本中加参数:- Djava . security manager 禁止执行 System exit 代的。

    2.进程崩溃问题

    排除以上低级死法,发现 Java 进程确实崩溃了,通常是由于 VM 本身不稳定造成的,这时在 TongWeb 的进程起始目录(通常是 TongWeb 的 bin 目录)会生成 javacore 开头的文本文件,收集这个 javacore 文件分析。

    3.僵尸进程

    进程会变成僵尸进程( defunct ),具体说明可百度。解决办法: 

    A 找到其父进程并杀掉。

    B 若杀不掉,只能重启机器。

    三、慢的问题

    Tong Web 上的应用系统慢也分多种情况,需要根据不同的现象进行不同的分析处理,重点是先要理清慢的现象,做好基本检直。

    1.最低级的慢

    (1) Tong Web 没有做基本的优化,两大影响性能的参数

    A 没有改启动脚本 JVM 内存,默认只有﹣Xmx512m,至少先设2G(-Xms2048m-

    Xmx2048m)

    B . linux 系统没有改 open files 值(默认1024),通常改法是修改/etc /security limits.conf ,在文件中加上两行:

    * soft nofile 65535

    * hard nofile 65535

    修改完后通过 linux 系统命令 ulimit -a查看 open files 值生效后重启 Tong Web ,

    (2)数据库没有做基本优化.

    (3)应用没有做基本优化,如:数据源连接池配置过小、日志还是 DEBUG 级别输出。

    (4)网速不够,通过网络测试软件,带宽太小,或是在 TongWeb 本机上访问( linux 也可以用 firefox )看慢不慢?若本机快,能过其它网段访问慢,则基本可以判断是网络问题

    (3)基本的性能测试都不做,直接上线,肯定出问题。

    2. CPU 占用高引起的慢

    通过 top 命令査看到 TongWeb 的 java 进程占用 CPU 很高,这时可以通过阿里的分析脚本 show - busy - java - threads.sh 来分析,该脚本可用于快速排査 Java 的 CPU 性能问题( top us 值过高),自动査出运行的 Java 进程中消耗 CPU 多的线程,打印出其线程栈,从而确定导致性能问题的方法调用。用法:

    show-busy-java-threads.sh - p Java 进程 id -c 要显示的线程栈数 a 输出记录到的文件

    Busy86.039%

    thread 125780/0x64b0stack of java process 

    要点:查看 CPU 确实高,脚本可百度査找下载,要在出现 CPU 高的问题时打该市令,学会看线程栈

    3.线程阻塞引起的慢

    这种现象通常表现为 CPU 使用不高, Tong Web 控制台访间正常,但应用所有页面访问都慢,这种情况通常是应用的 http 线程地出现阻塞导致的。出现这种问题时可使用 JDK 的 jstack 命令打出线程栈来分析,如: jstack java 进程 id log.txt ,输出到指定文件。重点看是不是 BLOCKED 线程很多,这些线程是不是 lock 在同一地址上,偶尔几个 BLOCKED 线程对系统不影响。

    java.lang.Thread.state:BLOCKED

    要点:会用 jstack 命令,要在出现慢的问题时打该命令,学会看线程栈

    4.数据源引起的慢

    这种现象通常表现为 CPU 使用不高, TongWeb 控制台访问正常,但应用跟数据库无关的页面访问正常,跟数据库有关的页面访问慢。这种分种情况:

    (1).数据源连接池占满, TongWeb 的 server . log 中可以看到数据源占满的日志(开源和Tong Web 数据源都会有),通过 jstack 可以看到线程阻塞在数据源上.可能是连接数过小引起的,若加大后还出现就有可能是存在连接泄露问题了,找应用代码泄露的地方改掉改不了应用代码就把泄漏超时泄漏回收同时设置上,这样到达超时时间后,强制回收数据库连接。开源连接池也有这参数。

    当超时后,以 WARNING 级别将该堆栈信息输出到日志,从日志中可以分忻到哪里存在未关闭的连接。日志示例如下:

    a potential connection leak detected for connection pool test

    (2).若部分数据库业务慢, TongWeb 数据源可记录下执行时间长的 SQL ,针对 SQL 进行优化。

    要点:熟悉 Tong Web 数据源和开源数据源的配置,会从数据库端分析

    5.内存引起的慢

    这种现象通常是 TongWeb 控制台和应用访部都很慢,日志中有 OutOMemoryError : Java heap space ',就跟前面说的死样,但进程还在。通过査看 bin 下 gclog 日志,或通过 jstat 命令,査看内存是否占满, Full GC 是否频繁。

     gc log 中有 Full GC 过于频繁的日志如下:

    1004277.657: Full GC 7442688K->7326004K(7909312K),14.7484964 secs ]

    1004292.491:[ Ful GC 7442688K->7234814K(7909312K),17.6059770 secs ]

    1004310.273:Full GC 7442687K->7327296K(7909312K),14.6444008 secs ]

    1004325.036:[ Full GC 7442687K->7328115K(7909312K),14.6859322 secs ]

     jstat :用于输出 java 程序内存使用情况,包括新生代、老年代、元数据区容量、垃圾回收情

    况。

    例: jstat - gcutil 进程号 2000 20

    上述命令输出进程 ID 为3618的内存使用情况(每2000呈秒输出一次,共输出20次)

    S0:幸存1区当前使用比例

     E :伊甸园区使用比例

     M :元数据区使用比例

    S1:幸存2区当前使用比例

    O:老年代使用比例

    CCS :压缩使用比例

     FGC :老年代垃圾回收次数

     GCT :垃圾回收消耗总时间

     YGC :年轻代垃圾回收次数

     FGCT :老年代垃圾回收消耗时间

    当确认内存满了,执行以下操作:

    (1)要求出现 OutOMemoryError : Java heap space 时不要重启 Java 进程,保留进程继续执行如下操作。

    (2)利用 JDK 的 jps - v 命令査出 Java 的进程号。

    (3)通过 jmap - histo - PID > mem txt 打出文本日志,生成过程很快,文件很小

    (4)采用 map 生成完整的内存镜像文件

     jmap - dump:live,fomat=b , file=heap.bin < PID> 在当前执行命令目录下生成,如果内存设为2G,则生成的内存镜像文件也有2G.

    (5)生成的 mem txt 文件可以用文本工具打开直接看,内存镜像文件可以用 MemoryAnalyzer 内存分析工具分忻。下载地址如:http://www.eclipse.ore/mat。分析这些文件需要用大内存机器才行,建议用64位 windows 机器,安装64位 MemoryAnalyzer 软件,物理内存至少为内存镜像文件的3倍。

    误区: JVM 内存够不够用主要看 GC (垃圾回收)情况,井非 JVM 内存设越大越好、并非 JVM 内存设越大越好、并非内存设越大越好,看内存使用最的曲线意义也不大

    要点:熟悉 JVM 的 GC 、会用 jstat 、 jmap 、 MemoryAnalyzer 分析 JVM 内存。

    6."大部分业务正常,只有个别业务慢”,这显然是应用该部分业务的问题,与中问件无关。推荐阿里开源的 java 诊断工具 Arthas ,可做源码级性能分析。

    7.除让手工方式, Tong Web 快照功能、 TongAPM 功能也可提供部分日志,具体请看

    ( TongWeb 用户手册》《 TongAPM 用户使用手册》

    四、总结

    通过以上说明,主要是让各位了解一下出现系统问题时,该如何描述问题,针对不同的问题现象该如何处理。处理这些问题的最基本要求是:

    1.理清问题现象。2.会通过 Linux 基本命令、 jstack 、 jstat 、 jmap 、 show - busy - java - threads . sh 、 jps 、 Arthas 、 MemoryAnalyzer 等工具和命令收集日志。具体使用方法可百度。

    3.会查看 GC 日志、线程日志、内存镜像日志,并熟悉 JVM 、 Tong Web 参数的调优、应用代码的优化。

     

  • 相关阅读:
    Java 函数式编程
    神经网络入门经典书籍,神经网络入门书籍推荐
    Kafka详解
    VR全景打造亮眼吸睛创意内容:三维模型、实景建模
    美妆穿搭带货直播稿 话术 脚本
    传输安全HTTPS
    【VUE 嵌套路由】
    SpringCloud - Config分布式配置中心
    stm32cubemx针对STM32F103系列问题挖坑-CMSIS-DAP不能下载调试
    Serverless Developer Meetup 杭州站精彩回顾!【附赠PPT】
  • 原文地址:https://blog.csdn.net/njq774327136/article/details/127567724