一:背景 1.讲故事 上个月 .NET调试训练营 里的一位老朋友给我发了一个 8G 的dump文件,说他的程序内存泄露了,一时也没找出来是哪里的问题,让我帮忙看下到底是怎么回事,毕竟有了一些调试功底也没分析出来,说明还是有一点复杂的,现实世界中的dump远比课上说的复杂的多. 还是那句话,找我分析是免费的,没有某软高额的工时费,接下来我们上 WinDbg 说话. 二:WinDbg 分析 1. 托管还是非托管泄露 这是我们首先就要做出的抉择,否则就会南辕北辙,可以使用 !address -summ…

当前环境 jdk == 1.8 httpasyncclient == 4.1.3 代码地址 git 地址:https://github.com/jasonGeng88/java-network-programming 背景 前不久,上线了一个新项目,这个项目是一个压测系统,可以简单的看做通过回放词表(http请求数据),不断地向服务发送请求,以达到压测服务的目的.在测试过程中,一切还算顺利,修复了几个小bug后,就上线了.在上线后给到第一个业务方使用时,就发现来一个严重的问题,应用大概跑了10多…

一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了托管堆上有 10w+ 的 byte[] 数组,并占用了大概 1.1G 的内存,在抽取几个 byte[] 的 gcroot 后发现没有引用,接下来就排查不下去了,虽然知道问题可能在 byte[],但苦于找不到证据. 那既然这么信任的找到我,我得要做一个相对全面的输出报告,不能辜负大家的信任哈,还是老规…

一:背景 1. 讲故事 前段时间有位朋友找到我,说他的程序内存占用比较大,寻求如何解决,截图就不发了,分析下来我感觉除了程序本身的问题之外,.NET5 在内存管理方面做的也不够好,所以有必要给大家分享一下. 二:WinDbg 分析 1. 托管还是非托管泄漏 这个还是老规矩 !address -summary 和 !eeheap -gc 组合命令排查一下. 0:000> !address -summary Mapping file section regions... Mapping module…

一:背景 1.讲故事 这周有个朋友找到我,说他的程序出现了内存缓慢增长,没有回头的趋势,让我帮忙看下到底怎么回事,据朋友说这个问题已经困扰他快一周了,还是没能找到最终的问题,看样子这个问题比较刁钻,不管怎么说,先祭出 WinDbg. 二:WinDbg 分析 1. 托管还是非托管泄露 一直关注这个系列的朋友都知道,托管和非托管的排查是两个体系,分析方式完全不一样,所以要鉴定是哪一块的内存问题,首先要用 !address -summary 观察进程的 虚拟内存 布局. 0:000> !address…

解Bug之路-记一次JVM堆外内存泄露Bug的查找 前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题.此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头.笔者将此Bug分析的过程写成博客,以飨读者. 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识,读者如果有兴趣了解请看ulk3(<深入理解linux内核第三版>) 内存泄露Bug现场 一个线上稳定运行了三年的系统,从物理机迁移到docker环境后,运行了一段…

记一次golang内存泄露 最近在QA环境上验证功能时,发现机器特别卡,查看系统内存,发现可用(available)内存仅剩200多M,通过对进程耗用内存进行排序,发现有一个名为application-manager的容器服务的内存占用达到700多M,该服务使用Gin框架对外提供操作k8s资源的简单功能,解析客户端请求,并将结果返回给客户端.由于是测试环境,访问量极少,但内存一直只增不减,从最初的10M,一直增加到700多M,最终由于OOM而被重启(Pod). 最初使用go pprof来尝试定位…

一:背景 1.讲故事 今天是的第四天,头终于不巨疼了,写文章已经没什么问题,赶紧爬起来写. 这个月初有位朋友找到我,说他的程序出现了CPU爆高,让我帮忙看下怎么回事,简单分析了下有两点比较有意思. 这是一个安全生产的信息管理平台,第一次听说,我的格局小了. 这是一个经典的 CPU 爆高问题,过往虽有分析,但没有刨根问底,刚好这一篇就来问一下底吧. 话不多说,我们上 WinDbg 说话. 二:WinDbg 分析 1. 真的 CPU 爆高吗? 别人说爆高不算,我们得拿数据说话不是,验证命令就是 !t…

背景:记一次常规的数据访问的时间分析(插入操作) 1. TCP三次握手 SYN ---> <--- SYN,ACK ACK ---> 花费时间: 386.718-385.784=0.934ms 2. 正常的消息交互 2.1. 服务器主动校验 <--- ServerGreeting LoginRequest ---> <--- ACK <--- Response 花费时间: 390.620-387.558=3.062ms 2.2 常规的请求响应 RequestQue…

一:背景 1. 讲故事 我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析 ,当时是给同济做项目升级,看过那篇文章的朋友应该知道,最后的结论是运维人员错误的将 IIS 应用程序池设成 32bit 导致了事故的发生,这篇算是后续,拖了好久才续上哈. 犹记得那些天老板天天找我们几个人开会,大概老板是在传导甲方给过来的压力,人倒霉就是这样,你说 CPU 爆高可怕吧,我硬是给摁下去了,好了,Memory 又爆高了,尼玛我又给摁下去了,接着数据库死锁又来了,你能体会到这种…