百度抓取网站频率,室内设计师联盟账号,国家商标注册官网入口,网页版抖音入口官网现场问题一般有以下几种问题 CPU,磁盘#xff0c;内存#xff0c;GC问题#xff0c;网络
同时例如jstack、jmap等工具也是不囿于一个方面的问题的#xff0c;基本上出问题就是df、free、top 三连#xff0c;然后依次jstack、jmap伺候#xff0c;具体问题具体分析即可。 …现场问题一般有以下几种问题 CPU,磁盘内存GC问题网络
同时例如jstack、jmap等工具也是不囿于一个方面的问题的基本上出问题就是df、free、top 三连然后依次jstack、jmap伺候具体问题具体分析即可。
CPU
1.top 查看 占用cpu多的线程 2.然后通过 top -H -p pid 来找到使用率比较高得线程
比如66 top -H -p 66
3.使用printf %x\n pid 得到nid
4.然后使用 jstack pid | grep nid -C10 来查看堆栈信息 频繁gc
使用 jstat -gc pid 1000 其中1000代表采样间隔ms 字段含义
s0c s1c 表示survivor 0 1 区域的容量 s0u s1u 表示survivor 0 1 区域的已使用的容量
ec eu 表示eden区域容量和已使用容量
mc mu metaspace元数据区的Commited Size metaspace元数据区的使用大小
CCSC Compressed class 的Committed Size 压缩类空间 调用的包太多 调大CompressedClassSpaceSize即可 CCSU Compressed class的使用大小
oc ou 表示 老年区容量和已经使用的容量
PC PU 表示持久代的内存容量和已经使用的容量
YGC YGT 表示 新生代gc发生的次数 和耗时
FGC FULL GC的次数
FGCT 表示老年代FUll GC发生的次数和耗时
CGC 并发GC次数
CGCT 并发GC消耗的时间
GCT b表示总的GC耗时 上下文切换
针对频繁上下文问题我们可以使用vmstat命令来进行查看 cs(context switch)一列则代表了上下文切换的次数。
如果我们希望对特定的pid进行监控那么可以使用 pidstat -w pid命令cswch和nvcswch表示自愿及非自愿切换。 磁盘
磁盘问题和cpu一样是属于比较基础的。首先是磁盘空间方面我们直接使用df -hl来查看文件系统状态 更多时候磁盘问题还是性能上的问题。我们可以通过iostat iostat -d -k -x来进行分析 最后一列%util可以看到每块磁盘写入的程度而rrqpm/s以及wrqm/s分别表示读写速度一般就能帮助定位到具体哪块磁盘出现问题了。
另外我们还需要知道是哪个进程在进行读写一般来说开发自己心里有数或者用iotop命令来进行定位文件读写的来源。 不过这边拿到的是tid我们要转换成pid可以通过readlink来找到pidreadlink -f /proc/*/task/tid/../..。 找到pid之后就可以看这个进程具体的读写情况cat /proc/pid/io 我们还可以通过lsof命令来确定具体的文件读写情况lsof -p pid 内存
free
堆内内存
内存问题大多还都是堆内内存问题。表象上主要分为OOM和StackOverflow。
OOM
JMV中的内存不足OOM大致可以分为以下几种
Exception in thread main java.lang.OutOfMemoryError: unable to create new native thread
这个意思是没有足够的内存空间给线程分配java栈基本上还是线程池代码写的有问题比如说忘记shutdown所以说应该首先从代码层面来寻找问题使用jstack或者jmap。如果一切都正常JVM方面可以通过指定Xss来减少单个thread stack的大小。
另外也可以在系统层面可以通过修改/etc/security/limits.confnofile和nproc来增大os对线程的限制 Exception in thread main java.lang.OutOfMemoryError: Java heap space
这个意思是堆的内存占用已经达到-Xmx设置的最大值应该是最常见的OOM错误了。解决思路仍然是先应该在代码中找怀疑存在内存泄漏通过jstack和jmap去定位问题。如果说一切都正常才需要通过调整Xmx的值来扩大内存。
Caused by: java.lang.OutOfMemoryError: Meta space
这个意思是元数据区的内存占用已经达到XX:MaxMetaspaceSize设置的最大值排查思路和上面的一致参数方面可以通过XX:MaxPermSize来进行调整(这里就不说1.8以前的永久代了)。
Stack Overflow
栈内存溢出这个大家见到也比较多。
Exception in thread main java.lang.StackOverflowError
表示线程栈需要的内存大于Xss值同样也是先进行排查参数方面通过Xss来调整但调整的太大可能又会引起OOM。 使用JMAP定位代码内存泄漏
上述关于OOM和StackOverflow的代码排查方面我们一般使用JMAPjmap -dump:formatb,filefilename pid来导出dump文件 通过mat(Eclipse Memory Analysis Tools)导入dump文件进行分析内存泄漏问题一般我们直接选Leak Suspects即可mat给出了内存泄漏的建议。另外也可以选择Top Consumers来查看最大对象报告。和线程相关的问题可以选择thread overview进行分析。除此之外就是选择Histogram类概览来自己慢慢分析大家可以搜搜mat的相关教程。 日常开发中代码产生内存泄漏是比较常见的事并且比较隐蔽需要开发者更加关注细节。比如说每次请求都new对象导致大量重复创建对象进行文件流操作但未正确关闭手动不当触发gcByteBuffer缓存分配不合理等都会造成代码OOM。
另一方面我们可以在启动参数中指定-XX:HeapDumpOnOutOfMemoryError来保存OOM时的dump文件。 gc问题和线程
gc问题除了影响cpu也会影响内存排查思路也是一致的。一般先使用jstat来查看分代变化情况比如youngGC或者fullGC次数是不是太多呀EU、OU等指标增长是不是异常呀等。
线程的话太多而且不被及时gc也会引发oom大部分就是之前说的unable to create new native thread。除了jstack细细分析dump文件外我们一般先会看下总体线程通过pstreee -p pid |wc -l。 或者直接通过查看/proc/pid/task的数量即为线程数量。 堆外内存
如果碰到堆外内存溢出那可真是太不幸了。首先堆外内存溢出表现就是物理常驻内存增长快报错的话视使用方式都不确定如果由于使用Netty导致的那错误日志里可能会出现OutOfDirectMemoryError错误如果直接是DirectByteBuffer那会报OutOfMemoryError: Direct buffer memory。
堆外内存溢出往往是和NIO的使用相关一般我们先通过pmap来查看下进程占用的内存情况pmap -x pid | sort -rn -k3 | head -30这段意思是查看对应pid倒序前30大的内存段。这边可以再一段时间后再跑一次命令看看内存增长情况或者和正常机器比较可疑的内存段在哪里。 我们如果确定有可疑的内存端需要通过gdb来分析gdb --batch --pid {pid} -ex dump memory filename.dump {内存起始地址} {内存起始地址内存块大小} 获取dump文件后可用heaxdump进行查看hexdump -C filename | less不过大多数看到的都是二进制乱码。
NMT是Java7U40引入的HotSpot新特性配合jcmd命令我们就可以看到具体内存组成了。需要在启动参数中加入 -XX:NativeMemoryTrackingsummary 或者 -XX:NativeMemoryTrackingdetail会有略微性能损耗。
一般对于堆外内存缓慢增长直到爆炸的情况来说可以先设一个基线jcmd pid VM.native_memory baseline。 然后等放一段时间后再去看看内存增长的情况通过jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail级别的diff。 可以看到jcmd分析出来的内存十分详细包括堆内、线程以及gc(所以上述其他内存异常其实都可以用nmt来分析)这边堆外内存我们重点关注Internal的内存增长如果增长十分明显的话那就是有问题了。
detail级别的话还会有具体内存段的增长情况如下图。 此外在系统层面我们还可以使用strace命令来监控内存分配 strace -f -e brk,mmap,munmap -p pid
这边内存分配信息主要包括了pid和内存地址。 不过其实上面那些操作也很难定位到具体的问题点关键还是要看错误日志栈找到可疑的对象搞清楚它的回收机制然后去分析对应的对象。比如DirectByteBuffer分配内存的话是需要full GC或者手动system.gc来进行回收的(所以最好不要使用-XX:DisableExplicitGC)。
那么其实我们可以跟踪一下DirectByteBuffer对象的内存情况通过jmap -histo:live pid手动触发fullGC来看看堆外内存有没有被回收。如果被回收了那么大概率是堆外内存本身分配的太小了通过-XX:MaxDirectMemorySize进行调整。如果没有什么变化那就要使用jmap去分析那些不能被gc的对象以及和DirectByteBuffer之间的引用关系了。
