jmap日志分析

未发现异常 。分别通过jstackl和jmapdump:业务反馈后台管理页面打开失败,报错 , 通过后台日志,发现zookeeper无法连接,找不到dubbo服务商,因为之前出现了zookeeper无法连接另一个在线服务的问题,是内存溢出,日志出现了OutOfMemory错误,所以我直接去服务器查看内存使用情况 , 使用psef|grepjava命令找出java进程号,然后使用jmapheappid命令检查jvm堆内存使用情况 。结果如下:如你所见,堆内存利用率为100% 。

当堆内存溢出时,使用psef|grepjava命令查看日志的文件路径 。对了,java程序启动的时候需要添加参数,这样在堆内存溢出的时候会自动生成hprof文件 。参数:xx: heapdumponotofmemoryerroxx:heapdumppath文件路径 。获取堆内存映像后,尽快重启并恢复在线服务 。
【jmap日志分析】
1、记一次Hive任务hang住的问题(2上线蜂巢任务偶尔会出现挂起的现象 。经过调查 , 确认是触发了Hive的一个bug,修复在Hive10569() 。用户的直线任务挂到了EndedJob之后,就再也没有结束 。请检查纱线日志 。该作业已成功运行 。我们在hiveserver上找到了工作的日志,没有发现什么异常 。我们分别通过jstackl和jmapdump对公司的ELK 日志系统和天巡过去一年使用的ES存储进行了性能优化 。本文主要讲的是在ELK架构中ES存储为日志时的性能优化方案 。随着越来越多的应用程序访问ELK,每天大约有230个新索引和3000万到5000万个新文档 。每天上午和下午是日志上传的高峰期 。当你在Kibana上查日志时 , 发现以下问题:(1) 日志会有540分钟的延迟;(2)多日志丢失 。

查看日志并找到许多write拒绝执行的情况 。从日志 , 我们可以看到ES的写线程池已经满了,执行任务的线程最大数量达到了16个,容量为200的队列已经容纳不下新的任务了 。再看线程池 , 我们也可以看到写线程池有很多写任务,所以我们需要优化ES的write的性能 。

2、Kubernetes集群 分析查看内存,CPU查看特定pod查看带有节点的特定节点,node node在docker容器内部不需要jstack命令就可以找到特定pod所在的节点,输入docker命令可以查看具体信息 。dockerstats命令用于返回正在运行的容器的实时数据流 。默认情况下 , stats使用参数A或all,该命令将每秒刷新一次输出,直到您按下CTRL C 。

CPUPerc和Memusage三列 。以下是可以在自定义格式中使用的所有占位符:有了这些信息,我们就可以完全根据自己的需要或偏好来控制dockerstats命令的输出 。JSON格式输出进入docker容器 , 发现没有jdk,只有jre命令无法通过设置PATH环境变量再次执行命令:发现没有权限 。这其实不是Bug,而是Docker从1.10版本开始增加的安全特性 。

3、内存泄露

    推荐阅读