勇往直前的专栏

最近某个应用程序老是卡，需要重启才能解决问题，导致被各种投诉，排查问题是Druid 连接池泄露引发的血案。。异常日志如下：ERROR-com.alibaba.druid.pool.GetConnectionTimeoutException:waitmillis60000,active50,maxActive50,creating0atcom.aliba...

背景经常做后端服务开发的同学，或多或少都遇到过 CPU 负载特别高的问题。尤其是在周末或大半夜，突然群里有人反馈线上机器负载特别高，不熟悉定位流程和思路的同学可能登上服务器一通手忙脚乱，定位过程百转千回。img对此，也有不少同学曾经整理过相关流程或方法论，类似把大象放进冰箱要几步，传统的方案一般是4步：1.topoderbywithP：1040//首先按进程负载...

首先说下问题现象：内网sandbox环境API持续1周出现应用卡死，所有api无响应现象刚开始当测试抱怨环境响应慢的时候 ，我们重启一下应用，应用恢复正常，于是没做处理。但是后来问题出现频率越来越频繁，越来越多的同事开始抱怨，于是感觉代码可能有问题，开始排查。首先发现开发的本地ide没有发现问题，应用卡死时候数据库，redis都正常，并且无特殊错误日志。开始怀疑是sandbox环境机器问题...

由来前些日子小组内安排值班，轮流看顾我们的服务，主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好，无论干什么都要上班的，若是轮到周末，那这一天算是毁了。不知道是公司网络广了就这样还是网络运维组不给力，网络总有问题，不是这边交换机脱网了就是那边路由器坏了，还偶发地各种超时，而我们灵敏地服务探测服务总能准确地抓住偶现的小问题，给美好的工作加点料。好几次值班组的小伙伴...

处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信...

前些日子小组内安排值班，轮流看顾我们的服务，主要做一些报警邮件处理、Bug 排查、运营 issue 处理的事。工作日还好，无论干什么都要上班的，若是轮到周末，那这一天算是毁了。不知道是公司网络广了就这样还是网络运维组不给力，网络总有问题，不是这边交换机脱网了，就是那边路由器坏了，还偶发地各种超时，而我们灵敏的服务探测服务总能准确地抓住偶现的小问题，给美好的工作加点料。好几次值班组的...