可用。于是我们对服务器上的状况进行了排查。 二.排查问题的过程 在这次的问题排查主要是围绕JVM的内存使用情况,生 ...
今天早上,收到一个报警,有个服务器的http往返时延飙升,同时曝出大量 ,很是折腾了一番,特记录下思考和排查经过。 .这是单纯的时延增大,还是有什么其他情况还未掌握 因为不知道是只有时延变大而已,还是同时有别的情况,第一反应是先看日志有没有异常。 看了一下,一片风平浪静,既是好消息也是坏消息。好消息是核心业务还在,不然一定会打日志,坏消息是日志提供不了任何信息。当然这也说明了我们的日志肯定有不到位 ...
2018-01-30 19:40 0 3962 推荐指数:
可用。于是我们对服务器上的状况进行了排查。 二.排查问题的过程 在这次的问题排查主要是围绕JVM的内存使用情况,生 ...
1、问题发现 Prometheus报警某服务的一个节点 Old GC过多,需要排查。 2、查看GC日志 使用tail -f gc.log命令查看异常节点的GC日志,从日志可以看出Young GC过于频繁,竟然在1s内有9次Young GC: 使用tail ...
前言 之前或多或少分享过一些内存模型、对象创建之类的内容,其实大部分人看完都是懵懵懂懂,也不知道这些的实际意义。 直到有一天你会碰到线上奇奇怪怪的问题,如: 线程执行一个任务迟迟没有返回,应用假死。 接口响应缓慢,甚至请求超时。 CPU 高负载运行。 这类问题并不 ...
转贴:http://my.oschina.net/flashsword/blog/205266 本文是一次线上OOM故障排查的经过,内容比较基础但是真实,主要是记录一下,没有OOM排查经验的同学也可以参考。 现象 我们之前有一个计算作业。最近经常出现不稳定,无法正常响应的情况。具体表现 ...
由于近期线上单量暴涨,第三方反馈部分工单业务存在查询处理失败现象,经排查是当前系统通过FeignClient调用下游系统出现部分超时失败(异常代码贴在下方)。 通过系统慢请求捕捉拦截,发现当前请求仅耗时1031毫秒,就触发Read timed out超时错误,本项 ...
解Bug之路-记一次线上请求偶尔变慢的排查 前言 最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场 这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过1s,让我们业务耗时监控的99.99线变得 ...
1、事件还原 昨天下午,收到一个504的告警,显然这是一个超时告警。当时由于手头有其他事情,没在意,就只是瞄了一眼,但是引起告警的方法很熟悉,是我写的,第一反应有点诧异。 诧异之后,继续处理手头的工作。 一小时过后,又收到同样的告警,显然不是偶尔,肯定是哪儿出问题了,于是开始排查。 报警 ...
我们的情况和这个朋友遇到的有点类似: https://blog.csdn.net/majianting/article/details/96476375 如我的域名是:yuming.api.com 如公网ip是:192.168.2.202 我线上的接口是:http://yuming.api.com ...