JMAP

​作者介绍 二马读书 ， 曾任职于阿里巴巴，每日优鲜等互联网公司，任技术总监，15年电商互联网经历。 很多人在面试时，会被问到这样的问题：遇到过什么系统故障？怎么解决的？下面是笔者根据自己15年互联网研发经历总结的多个线上故障真实案例。 本文图不多，但内容很干！理解为主，学以致用！ 故障一：JVM频繁FULL GC快速排查 在分享此案例前，先聊聊哪些场景会导致频繁Full GC： 内存泄漏（代码有问题，对象引用没及时释放，导致对象不能及时回收）。 死循环。 大对象。 尤其是大对象，80%以上的情况就是他。 那么大对象从哪里来的呢？ 数据库（包括MySQL和MongoDB等NoSQL数据库），结果集太大。 第三方接口传输的大对象。 消息队列，消息太大。 根据多年一线互联网经验，绝大部分情况是数据库大结果集导致。 好，现在我们开始介绍这次线上故障： 在没有任何发布的情况下，POP服务（ 接入 第三方商家的服务）突然开始疯狂Full GC，观察堆内存监控没内存泄漏，回滚到前一版本，问题仍然存在，尴尬了！！！ 按照常规做法，一般先用jmap导出堆内存快照（jmap -dump:format=b,file=文件名 [pid]），然后用mat等工具分析出什么对象占用了大量空间，再查看相关引用找到问题代码。这种方式定位问题周期会比较长，如果是关键服务，长时间不能定位解决问题，影响太大。

作者：红魔七号 https://yq.aliyun.com/articles/69520 前言 平时的工作中经常碰到很多疑难问题的处理，在解决问题的同时，有一些工具起到了相当大的作用，在此书写下来，一是作为笔记，可以让自己后续忘记了可快速翻阅，二是分享，希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具，大家一起进步。 闲话不多说，开搞。 Linux命令类 tail 最常用的tail -f tail -300f shopbase.log #倒数300行并进入实时监听文件写入模式 grep grep forest f.txt #文件查找 grep forest f.txt cpf.txt #多文件查找 grep 'log' /home/admin -r -n #目录下查找所有符合关键字的文件 cat f.txt | grep -i shopbase grep 'shopbase' /home/admin -r -n --include *.{vm,java} #指定文件后缀 grep 'shopbase' /home/admin -r -n --exclude *.{vm,java} #反匹配 seq 10 | grep 5 -A 3 #上匹配 seq 10 | grep 5 -B 3 #下匹配 seq 10 | grep 5 -C 3 #上下匹配，平时用这个就妥了 cat f

[ 你悄悄来，请记得带走一丝云彩 ] 测试岗必知必会 01 请描述如何划分缺陷与错误严重性和优先级别？ 给软件缺陷与错误划分严重性和优先级的通用原则：1. 表示软件缺陷所造成的危害和恶劣程度。2. 优先级表示修复缺陷的重要程度和次序。 严重性：1. 严重：系统崩溃、数据丢失、数据毁坏2. 较严重：操作性错误、结果错误、遗漏功能3. 一般：小问题、错别字、UI布局、罕见故障4. 建议：不影响使用的瑕疵或更好的实现。 优先级：1. 最高优先级：立即修复，停止进一步测试。2. 次高优先级：在产品发布之前必须修复。3. 中等优先级：如果时间允许应该修复。4. 最低优先级：可能会修复，但是也可能发布。 02 一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。 一套完整的测试应该由五个阶段组成： 1.测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。 2.测试设计将测试计划阶段制定的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。 3.测试开发建立可重复使用的自动测试过程。 4

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

1、性能测试包含了哪些软件测试（至少举出3种）？ 参考答案：负载测试;压力测试;容量测试; 负载测试（Load Testing） ：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。 压力测试（Stress Testing） ：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。 容量测试（Volume Testing） ：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。 或者在下面选择几项：并发测试；基准测试 ；争用测试；性能配置 ；负载测试；强度测试；容量测试 2、请问什么是性能测试、负载测试、压力测试？ 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试、压力测试参考答案如上题。 3、在给定的测试环境下进行，考虑被测系统的业务压力量和典型场景？ 负载测试是用来测定系统饱和状态、确定阀值。其特点有：这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“平均CPU利用率低于65%”等指标。

目前有的那些jvm工具，界面都太难看了，严重影响我的调bug心情 所以我打算直接用jmap来看内存中都有什么东西 但是为什么不直接看gc日志中的Full GC频率呢 因为这个东西跟jvm内存分配和内存大小有关系，而我关心的是内存积存趋势 比如说，举个极端的例子，jvm内存很小，那么肯定每时每刻都在Full GC 但是你的代码真的这么差吗，不一定 但是如果条件很好，jvm内存设定的很大，那么几个月内都不会很频繁的Full GC 但是你的代码真的这么好吗，也不一定 所以归根结底要看内存中的对象是不是一直在累积增长 那么jmap就是个不错的东西 1 2 3 4 5 6 7 8 9 10 我们知道jmap打印的东西，jmap -histo pid是这个样的： 又臭又长 而且下面的都是内存中只有几个的，没有价值 所以我打算只取前9行，jmap -histo pid | head -12 但是总不能手动输出这个东西，所以我打算用crontab来定时打印它 #!/bin/bash step=5 #间隔的秒数，不能大于60 echo "get in loop" for (( i = 0; i < 55; i=(i+step) )); do echo "in loop" oldifs="$IFS" IFS=$'\n' for lines in `jmap -histo 2866 | head -12

执行top查看cpu过高的进程： top -H -p 32933 查看其内部线程： cpu占用最高的是33215 printf "%x\n" 33215 获取33215的8进制值 81bf jstack -l 32933 > tempfile.txt 打印堆栈日志 jmap -dump:format=b,file=heap1.hprof 32933 可以查看jstack 指令的用法，注意：这里的pid不能直接用33215 ，要用父级线程的pid，不然会报错 Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding 解决方式：https://blog.csdn.net/u011250186/article/details/99676292 但过于麻烦，直接就用父进程的id导出jstack -l 32933 > tempfile.txt，就可以了 然后在tempfile.txt 文件中根据查找81bf，就能找到33215 的信息。 红色的就是我自己的代码中的问题代码，这样就能定位到自己的代码问题了。 来源： oschina 链接： https:/