go pprof 你真用对了吗

Hi, 使用多年的go pprof检查内存泄漏的方法居然是错的?! 起个好标题确实能增加访问量最近在做一个 Redis 的 Proxy 的项目，其中利用Redis 6.0 新加的 tracking 功能实现客户端缓存的功能，可以为某些特定的redis使用场景提高吞吐和延迟。当然，cache的实现也是有代价的。首先，cache的大小不能无限制的大，否则总有一点会把内存撑爆的；其次，cache的淘汰算法有多种方式，LRU、LFU等等，具体可以参考Cache replacement policies，不同的场景下各种淘汰算法的效果是不一样的；第三，对于大并发情况实现cache是有代价的，因为并发情况下对cache的访问需要加锁，而加锁就意味着有性能的损失。我在实现这个cache的过程中稍微偷了一下懒, 想尽量的减少锁的scope,结果导致内存泄漏的问题。本来cache占用的最大内存我设置为10GB, 结果过了个周末发现程序已经占用了80GB的内存了。当然本文不是要介绍这个项目的内存泄漏原因，而是介绍一下Go pprof工具查找内存泄漏的一个不太常用的方法。检查Go程序内存的使用情况最常用的就是Go标准库自带的pprof库了，可以通过http暴露出这个profile, 然后通过go tool pprof或者pprof工具命令行/web方式查看。比如下面的命令，可以获取服务器http://ip:port的堆信息，并且在本机9090端口启动一个服务器展示堆的信息。 ``` go tool pprof -http :9090 http://ip:port/debug/pprof/heap ``` 在堆信息中你可以查看分配的堆的大小和对象数量，或者当前没有释放的占用的堆的大小和对象数量。 ![](https://upload-images.jianshu.io/upload_images/28338950-0334d75e3a6d3f13.png) 正常情况下使用这个方式就可以比较直观的看到哪一段代码分配的内存比较多，然后确定那里容易产生内存泄漏。 **但是**, 分配堆内存比较多的地方并不一定产生内存泄漏，只能说明这个地方"曾经/正在"分配的堆内存比较大,或者分配的堆内存比较频繁俄安，这些分配的内存可能在之后就回收掉了。像Java的一些profiler工具一样， pprof也可以比较两个时间点的分配的内存的差值，通过比较差值，就容易看到哪些地方产生的内存"残留"的比较多，没有被内存释放，极有可能是内存泄漏的点。你可以通过下面的方式产生两个时间点的堆的profile,之后使用pprof工具进行分析。 1. 首先确保你已经配置了pprof的http路径，可以访问http://ip:port/debug/pprof/查看(如果你没有修改默认的pprof路径) 2. 导出时间点1的堆的profile: curl -s http://127.0.0.1:8080/debug/pprof/heap > base.heap, 我们把它作为基准点 3. 喝杯茶，等待一段时间后导出时间点2的堆的profile: curl -s http://127.0.0.1:8080/debug/pprof/heap > current.heap 4. 现在你就可以比较这两个时间点的堆的差异了: go tool pprof --base base.heap current.heap 操作和正常的go tool pprof操作一样，比如使用top查看使用堆内存最多的几处地方的内存增删情况： ![](https://upload-images.jianshu.io/upload_images/28338950-2a2ea399d15fb71a.png) 使用web命令会生成一个SVG文件，可能你需要使用浏览器打开它。或者你直接使用命令打开web界面: `go tool pprof --http :9090 --base base.heap current.heap`。 ![](https://upload-images.jianshu.io/upload_images/28338950-a5dfe68dee09fd61.png) > 原文地址： https://colobu.com/2019/08/20/use-pprof-to-compare-go-memory-usage/#more 关注获取更多好文 ![](https://upload-images.jianshu.io/upload_images/28338950-f5436cc836ef371b.png) 本文由[mdnice](https://mdnice.com/?platform=6)多平台发布

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 210,978评论 6赞 490
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 89,954评论 2赞 384
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 156,623评论 0赞 345
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 56,324评论 1赞 282
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 65,390评论 5赞 384
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 49,741评论 1赞 289
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 38,892评论 3赞 405
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 37,655评论 0赞 266
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 44,104评论 1赞 303
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 36,451评论 2赞 325
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 38,569评论 1赞 340
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 34,254评论 4赞 328
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 39,834评论 3赞 312
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 30,725评论 0赞 21
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,950评论 1赞 264
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 46,260评论 2赞 360
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 43,446评论 2赞 348

go pprof 你真用对了吗

推荐阅读更多精彩内容