首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

深入用户体验,揪出罪魁祸首——由NPM+APM完成性能故障点快速定位和解决

引子‍

最近,笔者所在公司-神州灵云的专家拜访一知名政企客户时,专家详细介绍了公司酷毙的一体化性能管理解决方案(从网络和应用端同时采集监控),客户挑衅地说:“我们这边有个真实的应用性能问题,如果你们能解决,才是真正的酷!”。

以往都是Presentation+Demo就可以,这次要来真格的,专家虽然有些意外,但自信满满的说:“来吧,还就怕你没问题”。

故障描述:

原来客户有个Coding应用,使用者从互联网访问,不断吐槽、投诉不断(再不解决就不用了)很多交易的响应时间超过了500毫秒,SLA承诺是300毫秒以内,这差距也太大了吧。因为网络设备和节点繁多,排障初期并不能确定故障点,客户花费了大量时间在防火墙和Nginx策略优化上,但是依然不见成效。

了解到这个情况,专家心里有谱了:“没事,先上我们的故障定位系统NPM”,部署架构是这样的:

‍‍1 -代表外联区,2 -代表核心交换区3 -代表应用服务区

定位问题:

外联区:‍在12月4日通过网络性能管理与诊断平台在外联区采集到的coding业务交易相关的URL来看,响应时间都在1秒以上,远远超出了客户的预定延时。

外联区业务响应时间1秒多

核心交换区:发现同样的业务访问,响应时间也是1秒也上。

‍‍核心交换区-涛声依旧

应用服务区:‍在硬件Nginx和应用服务器之间进行采集数据包分析诊断,发现业务流的响应时间仍然维持在1秒左右,最终可以确定问题是出现在应用服务器

结论‍:应用服务器服务所消耗的时间就是很慢。

到此,神州灵云专家向客户展示了分析过程和结果,告诉客户重点解决应用服务器不能快速响应的问题。

客户:“你们只是定位了到了服务器,没有告诉我服务器的哪里有问题?以及如何解决?不算”。

“应用的排障和优化难道不是应用开发商的事情吗?”专家问道!

客户说:“你们既然是端到端一体化性能故障分析解决方案就别客气了,应用开发商也不一定靠得住”

神州灵云专家笑道:“多亏我还留了后手,该APM故障解决器登场了”。那就让神州灵云的故障解决专家系统上线吧。

A是故障解决专家系统

安装故障专家系统的监听器在Coding服务器上。在交易查询页面中可以看到有相当一部分交易响应时间都在1秒甚至2秒以上,再次证明是应用服务器的问题才导致的过大延时。

服务器内部运行的业务响应时间

对比发现,凡是响应时间过大的交易的时间点上,均触发了Java的垃圾回收(FGC)机制,频繁地触发FGC,每次FGC消耗2秒,在这个2秒时间里面,服务器“停止”响应外部的所有请求。

‍垃圾回收一次需要2秒

定位内存配置问题:

永久带内存分配不合理一共才5G内存,分配给了永久代2.5G,导致别的内存区严重不够用,Java进程就不断的回收内存,导致系统变慢。

解决问题:

‍将Java启动参数的永久代内存调整为300M后,应用系统恢复正常,大部分业务请求都在300毫秒以内完成。至此大功告成

用户看了结果和分析后只挑大拇指:“神州灵云的一体化故障定位解决方案真不是吹的,经得住实战,是运维的好帮手!”

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181226A08NMY00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券