小弟写了个简单后台用来接收POST请求上传过来的文件，并保存到后台本地。在做测试的时候，每一次请求上传5个文件，5个文件大小总和大概在300-400k的范围，测试的时候模拟客户端并发1000个POST上传文件。后台处理完1000请求后 RES直接上到500MB，查看/debug/pprof/下的threadcreate也直接上到400多个，再并发第二次，第三次... 1000个POST请求，RES在600多MB就不再涨了，threadcreate涨到570以后，增长速度就放缓了，此后七八分钟不再有请求发送RES慢慢再回降到100MB左右，但是threadcreate一直没有降过。上个图吧
##1.服务开启：
####RES：
+
####heap：
+
##2.第一次并发1000个POST请求：
####处理完请求，RES：
+
####处理请求中的heap：
+
####处理完请求的heap：
+
heap上看不大懂，三个问题：
+**1)是否只需关注inuse？**
+**2)idle是出于空闲的堆，还未把内存返回给系统？**
+**3)HeapReleased是指已经还给系统的内存容量？**
##3.过一段时间，期间没有任何请求，RES就降到100MB左右
####gc截图：
+
gc也不是很明白，>__<
scvg10: 590 MB released
scvg10: inuse: 21, idle: 591, sys: 613, released: 590, consumed: 22 (MB)
是指已经释放掉590MB的内存给系统了？那为什么(5633205-5619348) objects 对象个数没降下来呢？
go是否因为避免频繁的申请释放内存，才没有很迅速将内存还给系统，600MB->100MB，期间没任何请求，等了大概7分钟吧
最后，就是threadcreate为什么不会降下来呢，开了那么多线程何用呢？
希望大神指点一二~~谢谢啦!
Re:go是否因为避免频繁的申请释放内存，才没有很迅速将内存还给系统，600MB->100MB，期间没任何请求，等了大概7分钟吧
是的，同样遇到这样的问题，一个服务组件一次请求返回数据32M左右，上百个兵法时，内存涨到12G以上，短时间内降不下来，就是因为这个原因。go已经不用这些内存，但是程序自己估计之后还是会用到这些内存所以就先不还给系统，直到过了段时间，才会释放掉。所以，我们为了解决这样的问题在程序内部debug.FreeOSMemory().
#1
今日阅读排行
一周阅读排行