转自:http://blog.51cto.com/chengxiaobai/2052530?cid=695076 故障:最近收到生产服务器的报警短信以及邮件,报警内容为:内存使用率高于70%. 使用top命令查看系统资源的使用情况,命令:top 如图可以看到java的进程内存使用率较高,java进程的内存使用率达到了70%+ 2.定位线程问题(通过命令查看9718进程的线程情况),命令:ps p 9718 -L -o pcpu,pmem,pid,tid,time,tname,cmd 由此可以看到

Java进程CPU使用率高排查 生产java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下.1.jps 获取Java进程的PID.2.jstack pid >> java.txt 导出CPU占用高进程的线程栈.3.top -H -p PID 查看对应进程的哪个线程占用CPU过高.4.echo "obase=16; PID" | bc 将线程的PID转换为16进制.5.在第二步导出的Java.txt中查找转换成为16进制的线程PID.找到对应的线

Java内存泄漏的排查总结 https://blog.csdn.net/fishinhouse/article/details/80781673(缺图见下一条)内存泄漏的解决方案(转载)https://blog.csdn.net/dyhdengyahui/article/details/80770654

1.现象:zabbix监控到防火墙内存使用率频繁超过80%,而FortiGate防火墙内存超过80%将开启自身保护模式而不能新加策略等. 2.分析:这种情况一般是某些进程再释放内存的时候卡住.可以先查看一下是那些进程占用的内存高,然后尝试通过kill重启. 3.解决: 1)diagnose sys top 2)执行diagnose sys kill 9 pid 或 执行diagnose sys kill 11 pid  (11表示不记录日志,9表示不记录) 注:kill表示强制停止当前进程,但是

这是个比较典型的java内存使用问题,定位过程也比较直接,但对新人还是有点参考价值的,所以就纪录了一下. 下面介绍一下在不了解系统代码的情况下,如何一步步分析和定位到具体代码的排查过程 (以便新人参考和自己回顾) 初步的现象 业务系统消费MQ中消息速度变慢,积压了200多万条消息,通过jstat观察到业务系统fullgc比较频繁,到最后干脆OOM了:  进一步分析 既然知道了内存使用存在问题,那么就要知道是哪些对象占用了大量内存. 很多人都会想到把堆dump下来再用MAT等工具进行分析,但du

上述内存使用率是正常的,实际使用的是buffers.

1.top命令对cpu进行排序shift+p 2.pwdx pid查找业务进程路径 3.top -Hp pid查看相关负载线程pid 4.printf “0x%x\n” 线程pid     // 将线程 PID转换为 16进制,为后面查找 jstack 日志做准备 5.jstack  进程 PID | vim +/十六进制线程PID -        // 例如:jstack 1040|vim +/0x431 - 更快的方法使用show-busy-java-threads.sh github地址

由来 前些日子小组内安排值班,轮流看顾我们的服务,主要做一些报警邮件处理.Bug 排查.运营 issue 处理的事.工作日还好,无论干什么都要上班的,若是轮到周末,那这一天算是毁了. 不知道是公司网络广了就这样还是网络运维组不给力,网络总有问题,不是这边交换机脱网了就是那边路由器坏了,还偶发地各种超时,而我们灵敏地服务探测服务总能准确地抓住偶现的小问题,给美好的工作加点料.好几次值班组的小伙伴们一起吐槽,商量着怎么避过服务保活机制,偷偷停了探测服务而不让人发现(虽然也并不敢). 前些天我就在周末

下面通过模拟实例分析排查Java应用程序CPU和内存占用过高的过程.如果是Java面试,这2个问题在面试过程中出现的概率很高,所以我打算在这里好好总结一下. 1.Java CPU过高的问题排查 举个例子,如下: package com.classloading; public class Test { static class MyThread extends Thread { public void run() { // 死循环,消耗CPU int i = 0; while (true) {

内存划分 1.JAVA内存主要划分为方法栈.方法区.堆. 2.方法栈上内存会自动释放: 3.方法区上主要加载了类的元信息.静态变量.常量.改区域又称为持久代(Perm Gen),默认是最小16M,最大64M.配置参数 -XX:PermSize=16m -XX:MaxPermSize=64m: 4.堆是按分代进行管理,主要分为新生代(New Gen)和旧生代(Old Gen或Tenuring Gen). 1)新生代又分为Eden Space,S0,S1三块区域. 2)Eden是new出来对象的出生

一.内存过高 1.内存过高一般有两种情况:内存溢出和内存泄漏 (1)内存溢出:程序分配的内存超出物理机的内存大小,导致无法继续分配内存,出现OOM报错 (2)内存泄漏:不再使用的对象一直占据着内存不释放,导致这块内存浪费掉,久而久之,内存泄漏的对象堆积起来,也会导致物理机的内存被耗尽,出现OOM报错 2.内存过高的检测办法:通常我们的Java服务器部署在Linux机器上面,可以通过jvm自带的命令进行一些检测 (1)查看对象的数目和占用内存大小 ①参数为Java程序的进程号,将结果导出到指定目录

linux Java项目CPU内存占用高故障排查 top -Hp 进程号 显示进程中每个线程信息,配合jstack定位java线程运行情况 # 线程详情 jstack 线程PID # 查看堆内存中的对象的情况,如果有大量对象在持续被引用,没有被释放掉,就产生了内存泄露,要结合代码,把不用的对象释放掉 jmap -histo 线程PID # 查看堆的使用情况,各个堆空间的占用情况 jmap -heap # 查询进程id垃圾回收情况 jstat -gcutil 线程PID

一.使用top命令查看占用高资源的java项目的进程ID(pid): top 二.查看该进程中的线程所占用资源的情况:top -Hp pid 三.查看该线程对应的16进制:printf %x 11129 打印并保存该进程中堆栈的使用信息日志:jstack -l 11095 >> jstack.log  四.查看该进程中使用高资源的线程的具体信息日志:vim jstack.log 查找上一步的16进制的线程id:/2b79 定位到问题代码: 以上是测试所用(自己写的死循环) 实际排查时却并没有发

一.内存过高 1.内存过高一般有两种情况:内存溢出和内存泄漏 (1)内存溢出:程序分配的内存超出物理机的内存大小,导致无法继续分配内存,出现OOM报错 (2)内存泄漏:不再使用的对象一直占据着内存不释放,导致这块内存浪费掉,久而久之,内存泄漏的对象堆积起来,也会导致物理机的内存被耗尽,出现OOM报错 2.内存过高的检测办法:通常我们的Java服务器部署在Linux机器上面,可以通过jvm自带的命令进行一些检测 (1)查看对象的数目和占用内存大小 ①参数为Java程序的进程号,将结果导出到指定目录

高cpu占用 1.top命令:Linux命令.可以查看实时的CPU使用情况.也可以查看最近一段时间的CPU使用情况. 2.PS命令:Linux命令.强大的进程状态监控命令.可以查看进程以及进程中线程的当前CPU使用情况.属于当前状态的采样数据. ps -mp pid -o THREAD,tid,time printf "%x\n" tid 3.jstack:Java提供的命令.可以查看某个进程的当前线程栈运行情况.根据这个命令的输出可以定位某个进程的所有线程的当前运行状态.运行代码,以

最近收到邮件报警,说内存使作率达到84%.如下图: 解决方法: A:可能是代码原因导致的问题: 1.使用命令:top 查看当前进程的状态 2.从上图可以看到PID:916的java进程占用内存较大.定位线程问题(通过命令查看PID 为25894 进程的线程情况),命令:# ps p 916 -L -o pcpu,pmem,pid,tid,time,tname,cmd 由此可以看到这PID:916的进程产生了很多线程.接下来就可以通过jstack查看内存使用的堆栈. 3.查看内存使用的堆栈:在这里

发现服务器的cpu使用率特别高 排查思路: -使用top或者mpstat查看cpu的使用情况# mpstat -P ALL 2 1Linux 2.6.32-358.el6.x86_64 (linux—host) 01/05/2016 _x86_64_ (24 CPU) 04:41:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle04:41:15 PM all 0.56 0.00 0.25 0.00 0.00 0.04

原文地址:http://www.voidcn.com/article/p-yehrvmep-uo.html 思路如下:Linux系统中可以用top命令查看进程使用CPU和内存情况,通过Runtime类的exec()方法执行命令"top",获取"top"的输出,从而得到CPU和内存的使用情况. 使用top命令获取系统信息: top -b -n -1 | sed -n '3p'(使用sed命令将top输出内容中的第三行打印出来) %Cpu(s):  6.5 us,  2

前言 CPU 是时分的,操作系统里面有很多线程,每个线程的运行时间由CPU决定,CPU会分给每一个线程一个时间片,时间片是一个很短的时间长度,如果在时间片内,线程一直占有,就是100%,我们应该意识到,CPU运行速度很快(主频非常高),除非是密集型耗费CPU的运算,其他类型的任务都会在小于时间片的时间内结束. 内存过高一般有两种情况:内存溢出和内存泄露 内存溢出: 程序分配的内存超过物理机的内存大小,导致无法继续分配内存,出现OOM报错 内存泄露: 不再使用的对象一直占据着内存不释放,导致这块内

JVM运行时内存结构回顾 在JVM相关的介绍中,有说到JAVA运行时的内存结构,简单回顾下 整体结构如下图所示,大致分为五大块 而对于方法区中的数据,是属于所有线程共享的数据结构 而对于虚拟机栈中数据结构,则是线程独有的,被保存在线程私有的内存空间中,所以这部分数据不涉及线程安全的问题 不管是堆还是栈,他们都是保存在主内存中的 线程堆栈包含正在执行的每个方法的所有局部变量(调用堆栈上的所有方法).线程只能访问它自己的线程堆栈. 由线程创建的局部变量对于创建它的线程以外的所有其他线程是不可见的.

1.公司业务调整,把一部分数据由Redis转至MongoDB,业务在测试环境正常,生产环境上线后发现压力一上来MongoDB的服务直接把CPU占满了,和开发的同学分析了一下也参考了一下百度上类似的问题,最后定位原因:未使用索引. 解决方法很简单:对应的关键字段创建索引即可. 参考命令如下: >use Data;                                            #进入数据库Data,注意区分大小写: >db.stats();