系统运行缓慢,CPU 100%,以及 Full GC 次数过多问题的排查思路

  • 时间:
  • 浏览:0
  • 来源:大发5分快3_极速5分PK10

对于不定时老会 再次出现的接口耗时比较严重的疑问图片,亲戚亲戚朋友的定位思路基本如下:首先找到该接口,通过压测工具不断加大访问力度,是因为说该接口饱含某个位置是比较耗时的,是因为亲戚亲戚朋友的访问的频率非常高,这样大多数的任务管理器最终都将阻塞于该阻塞点,本来通不要 个任务管理器具有相同的堆栈日志,亲戚亲戚朋友基本上就可不可不能不能 定位到该接口中比较耗时的代码的位置。如下是俩个 代码饱含比较耗时的阻塞操作通过压测工具得到的任务管理器堆栈日志:

可不可不能不能 看多,在任务管理器为9的Java任务管理器中各个任务管理器的CPU占用情况汇报,接下来亲戚亲戚朋友可不可不能不能 通过jstack命令查看任务管理器id为10的任务管理器为哪此耗费CPU最高。需用注意的是,在jsatck命令展示的结果中,任务管理器id都转去掉 了十六进制形式。可不可不能不能 用如下命令查看转换结果,也可不可不能不能 找俩个 科学计算器进行转换:

这里打印结果说明该任务管理器在jstack中的展现形式为0xa,通过jstack命令亲戚亲戚朋友可不可不能不能 看多如下信息:

经过底下的法子进行排查日后,亲戚亲戚朋友基本上就可不可不能不能 得出这里的Thread-0本来亲戚亲戚朋友要找的任务管理器,通过查看其堆栈信息,亲戚亲戚朋友就可不可不能不能 得到具体是在哪个位置是因为其指在等待图片情况汇报了。如下示例中则是在SyncTask的第8行是因为该任务管理器进入等待图片了。

通过top命令查看CPU情况汇报,是因为CPU比较高,则通过top -Hp 命令查看当前任务管理器的各个任务管理器运行情况汇报,找出CPU欠缺的任务管理器日后,将其任务管理器id转换为十六进制的表现形式,因此在jstack日志中查看该任务管理器主要在进行的工作。这里又分为并完正都是情况汇报

是因为是正常的用户任务管理器,则通过该任务管理器的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU;

是因为该任务管理器是VM Thread,则通过jstat -gcutil 命令监控当前系统的GC情况汇报,因此通过jmap dump:format=b,file=导出系统当前的内存数据。导出日后将内存情况汇报倒入eclipse的mat工具中进行分析即可得出内存中主本来哪此对象比较消耗内存,进而可不可不能不能 处里相关代码;

是因为通过top命令看多CPU无须高,因此系统内存占用率也比较低。此时就可不可不能不能 考虑算不算是因为另外并完正都是情况汇报是因为的疑问图片。具体的可不可不能不能 根据情况汇报汇报分析:

是因为是接口调用比较耗时,因此是不定时老会 再次出现,则可不可不能不能 通过压测的法子加大阻塞点老会 再次出现的频率,从而通过jstack查看堆栈信息,找到阻塞点;

是因为是某个功能老会 老会 再次出现停滞的情况汇报,或多或少情况汇报也无法复现,此时可不可不能不能 通不要 次导出jstack日志的法子对比哪此用户任务管理器是老会 都指在等待图片情况汇报,哪此任务管理器本来是因为指在疑问图片的任务管理器;

是因为通过jstack可不可不能不能 查看多死锁情况汇报,则可不可不能不能 检查产生死锁的俩个 任务管理器的具体阻塞点,从而处里相应的疑问图片。

该任务管理器下的各个任务管理器运行情况汇报如下:

对于或多或少情况汇报,比较典型的例子本来,亲戚亲戚朋友某个接口访问老会 需用2~3s助于返回。这是比较麻烦的并完正都是情况汇报,是因为一般来说,其消耗的CPU不要 ,因此占用的内存本来高,也本来说,亲戚亲戚朋友通过上述并完正都是法子进行排查是无法处里或多或少疑问图片的。因此是因为本来的接口耗时比较大的疑问图片是不定时老会 再次出现的,这就是因为了亲戚亲戚朋友在通过jstack命令即使得到了任务管理器访问的堆栈信息,亲戚亲戚朋友也这样判断具体哪个任务管理器是正在执行比较耗时操作的任务管理器。

处里过线上疑问图片的同学基本上一定会遇到系统老会 运行缓慢,CPU 3000%,以及Full GC次数不要 的疑问图片。当然,哪此疑问图片的最终是因为的直观疑问图片本来系统运行缓慢,因此有多量的报警。本文主要针对系统运行缓慢或多或少疑问图片,提供该疑问图片的排查思路,从而定位出疑问图片的代码点,进而提供处里该疑问图片的思路。

相对来说,或多或少情况汇报是最容易老会 再次出现的,尤其是新功能上线时。对于Full GC较多的情况汇报,其主要有如下俩个 底部形态:

代码中一次获取了多量的对象,是因为内存溢出,此时可不可不能不能 通过eclipse的mat工具查看内存饱含哪此对象比较多;

内存占用不高,因此Full GC次数还是比较多,此时是因为是显示的System.gc()调用是因为GC次数不要 ,这可不可不能不能 通过去掉 -XX:+DisableExplicitGC来禁用JVM对显示GC的响应。

这可不可不能不能不能 看多,在请求UserController的日后,是因为该Controller进行了俩个 比较耗时的调用,是因为该任务管理器的CPU老会 指在3000%。亲戚亲戚朋友可不可不能不能 根据堆栈信息,直接定位到UserController的34行,查看代码中具体是哪此是因为是因为计算量这样之高。

在前面第或多或少中,亲戚亲戚朋友讲到,CPU欠缺是因为是系统频繁的进行Full GC,是因为系统缓慢。而亲戚亲戚朋友平常也是因为遇到比较耗时的计算,是因为CPU欠缺的情况汇报,此时查看法子真是与底下的非常类似。首先亲戚亲戚朋友通过top命令查看当前CPU消耗欠缺的任务管理器是哪个,从而得到任务管理器id;因此通过top -Hp 来查看该任务管理器饱含哪此任务管理器CPU欠缺,一般超过3000%本来比较高的,3000%左右是合理情况汇报。本来亲戚亲戚朋友就能得到CPU消耗比较高的任务管理器id。接着通过该任务管理器id的十六进制表示在jstack日志中查看当前任务管理器具体的堆栈信息。

对于这并完正都是情况汇报,通过查看CPU和系统内存情况汇报是无法查看出具体疑问图片的,是因为它们相对来说完正都是具有一定阻塞性操作,CPU和系统内存使用情况汇报完正都是高,因此功能却太快了 了 。下面亲戚亲戚朋友就通过查看系统日志来一步一步甄别上述几种疑问图片。

可不可不能不能 看多,在jstack日志的底部,其直接帮亲戚亲戚朋友分析了日志中指在哪此死锁,以及每个死锁的任务管理器堆栈信息。这里亲戚亲戚朋友有俩个 用户任务管理器分别等待图片图片对方释放锁,而被阻塞的位置完正都是在ConnectTask的第5行,此时亲戚亲戚朋友就可不可不能不能 直接定位到该位置,因此进行代码分析,从而找到产生死锁的是因为。

对于死锁,或多或少情况汇报基本上很容易发现,是因为jstack可不可不能不能 帮助亲戚亲戚朋友检查死锁,因此在日志中打印具体的死锁任务管理器信息。如下是俩个 产生死锁的俩个 jstack日志示例:

相对来说,这是老会 再次出现频率最高的并完正都是线上疑问图片,因此它们会直接是因为系统不可用。另外有几种情况汇报也会是因为某个功能运行缓慢,因此不至于是因为系统不可用:

这里需用说明的是,亲戚亲戚朋友在判断算不算为用户任务管理器时,可不可不能不能 通过任务管理器最前面的任务管理器名来判断,是因为一般的框架的任务管理器命名完正都是非常规范的,亲戚亲戚朋友通过任务管理器名就可不可不能不能 直接判断得出该任务管理器是或多或少框架中的任务管理器,或多或少任务管理器基本可不可不能不能不能 排除掉。而剩余的,比如底下的Thread-0,以及亲戚亲戚朋友可不可不能不能 辨别的自定义任务管理器名,哪此完正都是亲戚亲戚朋友需用排查的对象。

对于或多或少情况汇报,这是比较罕见的并完正都是情况汇报,因此也是有是因为老会 再次出现的,因此是因为其具有一定的“不可复现性”,因而亲戚亲戚朋友在排查的日后是非常难以发现的。笔者本来就遇到过类似的或多或少情况汇报,具体的场景是,在使用CountDownLatch时,是因为需用每俩个 并行的任务都执行完成日后才会唤醒主任务管理器往下执行。而当时亲戚亲戚朋友是通过CountDownLatch控制多个任务管理器连接并导出用户的gmail邮箱数据,这其饱含俩个 任务管理器连接上了用户邮箱,因此连接被服务器挂起了,是因为该任务管理器老会 等待图片图片服务器的响应。最终是因为亲戚亲戚朋友的主任务管理器和其余哪几个任务管理器都指在WAITING情况汇报。

这里的VM Thread一行的最后显示nid=0xa,这里nid的意思本来操作系统任务管理器id的意思。而VM Thread指的本来垃圾回收的任务管理器。这里亲戚亲戚朋友基本可不可不能不能不能 取舍,当前系统缓慢的是因为主本来垃圾回收过于频繁,是因为GC停顿时间较长。亲戚亲戚朋友通过如下命令可不可不能不能 查看GC的情况汇报:

首先亲戚亲戚朋友可不可不能不能 使用top命令查看系统CPU的占用情况汇报,如下是系统CPU较高的俩个 示例:

代码中某个位置读取数据量较大,是因为系统内存耗尽,从而是因为Full GC次数不要 ,系统缓慢;

代码饱含比较耗CPU的操作,是因为CPU欠缺,系统运行缓慢;

经过mat工具分析日后,亲戚亲戚朋友基本上就能取舍内存中主本来哪个对象比较消耗内存,因此找到该对象的创建位置,进行处里即可。这里的主本来PrintStream最多,因此亲戚亲戚朋友也可不可不能不能 看多,其内存消耗量必须12.2%。也本来说,其还欠缺以是因为多量的Full GC,此时亲戚亲戚朋友需用考虑另外并完正都是情况汇报,本来代码是因为第三方依赖的饱饱含显示的System.gc()调用。或多或少情况汇报亲戚亲戚朋友查看dump内存得到的文件即可判断,是因为其会打印GC是因为:

对于本来的疑问图片,查看多jstack日志的读者应该都知道,正常情况汇报下,线上大多数任务管理器完正都是指在TIMED_WAITING情况汇报,而亲戚亲戚朋友这里出疑问图片的任务管理器指在的情况汇报与其是一模一样的,这就非常容易混淆亲戚亲戚朋友的判断。处里或多或少疑问图片的思路主要如下:

在这里亲戚亲戚朋友就可不可不能不能 区分是因为CPU欠缺的是因为具体是Full GC次数不要 还是代码饱含比较耗时的计算了。是因为是Full GC次数不要 ,这样通过jstack得到的任务管理器信息会是类似VM Thread类似的任务管理器,而是因为是代码饱含比较耗时的计算,这样亲戚亲戚朋友得到的本来俩个 任务管理器的具体堆栈信息。如下是俩个 代码饱含比较耗时的计算,是因为CPU欠缺的任务管理器信息:

等待图片一段时间日后,比如10s,再次对jstack日志进行grep,将其导出到本来文件,如a2.log,结果如下所示:

可不可不能不能 看多,这里FGC指的是Full GC数量,这里高达6793,因此还在不断增长。从而进一步证实了是是因为内存溢出是因为的系统缓慢。这样这里确认了内存溢出,因此怎么才能 才能 查看你是哪此对象是因为的内存溢出呢,或多或少可不可不能不能 dump出内存日志,因此通过eclipse的mat工具进行查看,如下是其展示的俩个 对象树底部形态:

重复步骤2,待导出3~俩个 文件日后,亲戚亲戚朋友对导出的文件进行对比,找出其中在这哪几个文件中老会 都指在的用户任务管理器,或多或少任务管理器基本上就可不可不能不能 确认是饱含了指在等待图片情况汇报有疑问图片的任务管理器。是因为正常的请求任务管理器是不要 在20~300s日后还是指在等待图片情况汇报的。

经过排查得到哪此任务管理器日后,亲戚亲戚朋友可不可不能不能 继续对其堆栈信息进行排查,是因为该任务管理器并完正都是就应该指在等待图片情况汇报,比如用户创建的任务管理器中指在空闲情况汇报的任务管理器,这样或多或少任务管理器的堆栈信息中是不要 饱含用户自定义的类的。哪此可不可不能不能 排除掉,而剩下的任务管理器基本上就可不可不能不能 确认是亲戚亲戚朋友要找的有疑问图片的任务管理器。通过其堆栈信息,亲戚亲戚朋友就可不可不能不能 得出具体是在哪个位置的代码是因为该任务管理器指在等待图片情况汇报了。

对于线上系统老会 产生的运行缓慢疑问图片,是因为该疑问图片是因为线上系统不可用,这样首先需用做的本来,导出jstack和内存信息,因此重启系统,尽快保证系统的可用性。或多或少情况汇报是因为的是因为主要有并完正都是:

可不可不能不能 看多,有俩个 Java任务管理器此时CPU占用量达到了98.8%,此时亲戚亲戚朋友可不可不能不能 克隆好友该任务管理器id9,因此使用如下命令查看呢该任务管理器的各个任务管理器运行情况汇报:

本文主本来提出了并完正都是常见的是因为线上功能缓慢的疑问图片,以及排查思路。当然,线上的疑问图片老会 再次出现的形式是多种多样的,本来一定局限于这几种情况汇报,是因为亲戚亲戚朋友助于仔细分析哪此疑问图片老会 再次出现的场景,就可不可不能不能 根据情况汇报汇报具体分析,从而处里相应的疑问图片

从底下的日志可不可不能不能 看你出,这里有多个任务管理器都阻塞在了UserController的第18行,说明这是俩个 阻塞点,也本来是因为该接口比较缓慢的是因为。

比如这里第一次GC是是因为System.gc()的显示调用是因为的,而第二次GC则是JVM主动发起的。总结来说,对于Full GC次数不要 ,主要有以下并完正都是是因为:

代码某个位置有阻塞性的操作,是因为该功能调用整体比较耗时,但老会 再次出现是比较随机的;

某个任务管理器是因为并完正都是是因为而进入WAITING情况汇报,此时该功能整体不可用,因此无法复现;

是因为锁使用不当,是因为多个任务管理器进入死锁情况汇报,从而是因为系统整体比较缓慢。

top -Hp 9

本文主要讲解了线上是因为老会 再次出现的并完正都是是因为系统缓慢的情况汇报,完正分析了每项情况汇报产生时的疑问图片,是因为根据疑问图片亲戚亲戚朋友可不可不能不能 通过哪此法子定位得到是或多或少是因为是因为的系统缓慢。简要的说,亲戚亲戚朋友进行线上日志分析时,主要可不可不能不能 分为如下步骤:

通过grep在jstack日志中找出所有的指在TIMED_WAITING情况汇报的任务管理器,将其导出到某个文件中,如a1.log,如下是俩个 导出的日志文件示例: