线上服务请求慢问题排查

标签: 线上 服务 问题 | 发表时间:2020-09-08 07:35 | 作者:敲代码不如跳舞
出处:https://juejin.im/backend

问题出现

收到测试的消息,项目页面打开很慢。

不想收到的消息

问题排查

  1. 查看线上JVM监控平台,发现每分钟由于GC暂停的时间 30~50s。

    每分钟GC暂停时间每分钟GC暂停时间
  2. 进入线上机器, jstat -gccause pid time,发现老年代的占比一直在99%左右,并且发生full gc之后,变化很小。

    然后,查看线上gc日志,发现老年代的空间在full gc 前后基本无变化。(大概确定是内存泄漏了)

gc日志gc日志
  1. 于是乎,jmap整个dump文件。在dump文件生成之后,先把线上机器重启了(因为是老项目,最近没有重启,所以基本上可以判断不是由于业务代码的逻辑问题,所以先重启保证线上可用。重启后观察内存情况,发现是正常的。)
  2. 漫长地等待dump文件的下载(也就3.47G,公司的网也就下了快2小时,排查问题的主要障碍是公司的网络。)
dump文件

分析原因

  1. Jprofiler打开dump文件。这个char[]的大小 和 ConcurrentHashMap$Node的数量,极为可疑。
分析dump文件分析dump文件
  1. 切换到Biggest Objects。发现FallbackModuleMappingRule这个对象里存在一个名为cache的ConcurrentHashMap对象占了2475MB的大小(线上老年代才2.5G)。
分析dump文件分析dump文件
  1. 查看map的具体节点信息,发现存的是url的path以及其对应的module(webx3项目)。
分析dump文件分析dump文件
  1. 看了一下FallbackModuleMappingRule这个类,发现是用来映射 module 与 screen 里的类 的关系的。出现url的path的原因是因为,url被编码后?被整成了%3F,然后被认为整个路径都是path,所以找不到module,就用了整个路径。

    FallbackModuleMappingRuleFallbackModuleMappingRule
  2. 照理说不该有这种被编码好几次的url。所以去链路上瞅了瞅类似请求的user-agent,发现是搜索引擎蜘蛛。(靠,能不能专业点,要爬就好好爬)

    %253F 解码一次是 %3F ,再解码一次是 ? 。

user-agentuser-agent user-agentuser-agent

解决方式

  1. filter对url做处理。
  2. 反射获取FallbackModuleMappingRule的cache,定时清空。
  3. ...

PS

维护老项目太nm难了。

推荐《 问题出现我再告诉大家

相关 [线上 服务 问题] 推荐:

线上存储服务崩溃问题分析记录

- - codedump
上周我们的存储服务在某个线上项目频繁出现崩溃,花了几天的时间来查找解决该问题. 由于问题在线上发生,较难重现,首先想到的是能不能加上更多的信息,在问题出现时提供更多的解决思路. 首先,我们的代码里,在捕获到进程退出的信号比如SIGABRT、SIGSEGV、SIGILL等信号时,会打印出主线程的堆栈,用于帮助我们发现问题.

线上服务请求慢问题排查

- - 掘金后端
收到测试的消息,项目页面打开很慢. 查看线上JVM监控平台,发现每分钟由于GC暂停的时间 30~50s. jstat -gccause pid time,发现老年代的占比一直在99%左右,并且发生full gc之后,变化很小. 然后,查看线上gc日志,发现老年代的空间在full gc 前后基本无变化.

线上服务增加varnish缓存

- - CSDN博客互联网推荐文章
(1)是基于内存缓存,重启后数据将消失. (2)利用虚拟内存方式,io性能好. (3)支持设置0~60秒内的精确缓存时间. (4)VCL配置管理比较灵活. (5)32位机器上缓存文件大小为最大2G. (6)具有强大的管理功能,例如top,stat,admin,list等. (7)状态机设计巧妙,结构清晰.

Ubuntu开启IPV6,解决Gmail等google服务不稳定问题

- lin - 〖好记性不如烂笔头─Ubuntu Note〗
我是个离不开google服务的人. 花钱买的SSH服务也时不时抽风. 在结果中应该能看见一个叫 teredo 的虚拟网卡. 现在您的浏览器应该可以访问 https://ipv6.google.com 了. 把host列表拷贝进去,hosts列表发布地址:http://docs.google.com/View?id=dfkdmxnt_61d9ck9ffq.

在服务器上排除问题的头五分钟

- - 博客园_新闻
英文原文: First 5 Minutes Troubleshooting A Server,编译: @老码农的自留地. 我们团队为上一家公司承担运维、优化和扩展工作的时候,我们碰到了各种不同规模的性能很差的系统和基础设备(大型系统居多,比如 CNN 或者世界银行的系统). 要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档,基本上这过程都会惨痛到让我们留下深刻的记忆.

探讨如何减少Linux服务器TIME_WAIT过多的问题

- - 企业架构 - ITeye博客
       今天早上一上班,有同事就反映公司好几个网站都打不开,登陆数据库. 服务器(windows),发现很卡,于是重启了下服务器,进入系统后,没过一会问题依旧,查看了下系统进程,发现mysql占用率达到99%,可以肯定的是mysql连接出现问题:.       根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用.

创建微服务?请先回答这10个问题

- - ITeye资讯频道
乍一看微服务似乎很容易构建,但是要真正构建微服务,要完成的工作可比在容器里运行一些代码,并在这些代码间使用HTTP请求进行通信,要多得多. 在开发新的微服务之前——必须得在新服务部署到生产环境之前——你需要回答下面这10个重要的问题. 当考虑到测试时,微服务有一些优势和劣势. 一方面,定义良好的一小段功能的小型服务的单元测试,要比测试整个大型应用程序容易得多.

如何解决微服务架构中的雪崩问题?

- - 企业架构 - ITeye博客
记得在三年前公司因为业务发展需要,就曾经将单体应用迁移到分布式框架上来. 当时就遇到了这样一个问题:系统仅有一个控制单元,它会调用多个运算单元,如果某个运算单元(作为服务提供者)不可用,将导致控制单元(作为服务调用者)被阻塞,最终导致控制单元崩溃,进而导致整个系统都面临着瘫痪的风险. 那个时候还不知道这其实就是服务的雪崩效应,雪崩效应好比就是蝴蝶效应,说的都是一个小因素的变化,却往往有着无比强大的力量,以至于最后改变整体结构、产生意想不到的结果.

线上性能问题初步排查方法

- - 并发编程网 - ifeve.com
有时候有很多问题只有在线上或者预发环境才能发现,而线上又不能Debug,所以线上问题定位就只能看日志,系统状态和Dump线程,本文只是简单的介绍一些常用的工具,帮助定位线上问题. 1: 首先使用TOP命令查看每个进程的情况,显示如下:. 我们的程序是Java应用,所以只需要关注COMMAND是Java的性能数据,COMMAND表示启动当前进程的命令,在Java进程这一行里可以看到CPU利用率是300%,不用担心,这个是当前机器所有核加在一起的CPU利用率.

一次线上问题排查所引发的思考

- - crossoverJie's Blog
之前或多或少分享过一些 内存模型、 对象创建之类的内容,其实大部分人看完都是懵懵懂懂,也不知道这些的实际意义. 直到有一天你会碰到线上奇奇怪怪的问题,如:. 线程执行一个任务迟迟没有返回,应用假死. 接口响应缓慢,甚至请求超时. 这类问题并不像一个空指针、数组越界这样明显好查,这时就需要刚才提到的内存模型、对象创建、线程等相关知识结合在一起来排查问题了.