Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

好像有内存泄漏 #415

Closed
liaoyangyang opened this issue Mar 8, 2017 · 95 comments
Closed

好像有内存泄漏 #415

liaoyangyang opened this issue Mar 8, 2017 · 95 comments

Comments

@liaoyangyang
Copy link

liaoyangyang commented Mar 8, 2017

3月的服务器版本好像都有内存泄漏(用过3月1号,2号,3号),我用的是linux_amd64(client 和server都是),2月份的好像没有,我现在换成2月的试试,配置什么的都没有改过,还是说新版本有新策略???
qq 20170308102428

图片中很急的拐点都是我重启的时候,我的vps本来每天5点左右就会重启

@everfly
Copy link

everfly commented Mar 8, 2017

有类似同样问题,不过没这么严重,之前本来想发个issue,后来不是太确定就删了。
tim 20170308103701
服务器内存占用在4、5、6这几天比较严重,然后就换回二月版本了,后面就没有类似问题了。
具体表现为流量较大时内存占用上升差不多100M左右,二月版本也就上升十多兆

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

哦? 确实有内存使用方面的调整,检查一下。

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

这个版本改动比较大,可能会有些问题。

@dearneo
Copy link

dearneo commented Mar 8, 2017

内存的确比之前的版本高些,但似乎没你们的严重。每天6点定时重启kcptun服务

20170308104213

@liaoyangyang
Copy link
Author

嗯,我试试,不过我的服务器好几个人再用,估计得一两天才能大致看出是否改善

@everfly
Copy link

everfly commented Mar 8, 2017

@xtaci 经过两个小时左右的连续播放测试,使用版本kcptun-linux-amd64-20170308.tar.gz,状况如下:内存使用率上升趋势变缓,但是最终使用率还是很高,
这个是连续两小时左右播放后的内存使用率:
1
然后结束掉kcptun进程后的内存使用率:
4
服务器后台统计如下:
3
其中10点的时候内存占用率为:
2017/03/08 10:00:02: Allocated MB: 714 Used MB: 319
12:55时占用率:
2017/03/08 12:55:02: Allocated MB: 813 Used MB: 414
这期间其它进程和平时一样,只多开了一个kcptun进程

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

确实很奇怪,我的vultr平时也就最多70MB

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

@everfly 用我最新的release测试吧,设计上确实会多用内存,但不至于会这么夸张。

另外 尝试 GOGC=20

@everfly
Copy link

everfly commented Mar 8, 2017

好的,我用最新版本试试看

@bettermanbao
Copy link

我也观察到这个现象了,只有一个人在用。
刚才看了下内存飙到200多M,以前100多M都很少见。

麻烦 @xtaci 大神看看吧,谢谢!

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

@bettermanbao 客户端还是服务器

@bettermanbao
Copy link

服务器 @xtaci

@bettermanbao
Copy link

刚换了0308版,等我看看是否改善。

@liaoyangyang
Copy link
Author

今天的release服务器版本应该还有内存泄漏,启动时设置了GOGC=20
今天下午2点使用release版本,播了大概45分钟youtube 视频,之后轻度使用
screenshot from 2017-03-08 16-41-45

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

kcptun-linux-386-20170308.tar.gz
kcptun-linux-amd64-20170308.tar.gz

这个是之前的内存控制/发送队列方式。

@liaoyangyang
Copy link
Author

@xtaci client和server 不需要版本一致吧

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

不需要一致,但最好一致

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

3月的版本结构上优化比较大,肯定会有不少问题,感谢各位的测试。

@bettermanbao
Copy link

负优化吗?哈哈哈哈哈。。。。

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

主要是针对服务器的优化,大量连接 > 5K 的优化措施,针对游戏的。

@bettermanbao
Copy link

你还把kcptun用在生产环境啊???

@xtaci
Copy link
Owner

xtaci commented Mar 8, 2017

@bettermanbao 好多把kcp-go用于生产环境的啊, 生产环境远没有kcptun的用法那么高要求。游戏的话甚至不需要FEC,窗口32就足够了。但是连接数非常高。kcptun的另一个目的是把kcp-go推到极致。

@liaoyangyang
Copy link
Author

qq 20170309085228
@xtaci 使用你在最近回复的版本(之前的内存控制),没有使用GOGC变量,从昨天下午5点左右开始启动,今天早上5点定时重启,几乎没有使用vps

@xtaci
Copy link
Owner

xtaci commented Mar 9, 2017

是问题解决了?

@liaoyangyang
Copy link
Author

额,没有吧,内存还是缓慢的增长,你看看趋势,从昨天17:00 到今天5:00 ,从今天5:00重启之后还在增长

@nylqd
Copy link

nylqd commented Mar 9, 2017

image
同样发现这个问题,虽然没有这么严重,内存占用在缓慢上升

@xtaci
Copy link
Owner

xtaci commented Mar 9, 2017

2017-03-09 10 45 56

这是我跑了12个小时的结果, 26M 服务器,差别这么大。

@liaoyangyang
Copy link
Author

我的可能是有好几个人在使用的缘故,内存上升的比较快,并且我在服务端运行了3个server程序,不过一个空跑,一个几乎不用,这两个没什么变化,一个正常使用,可以不怎么使用的一个5M内存,一个11M左右,正常使用的增长快

[root@localhost ~]# 
[root@localhost ~]# ps aux|grep server_
root       131  0.4 23.1 190644 121584 ?       Sl   16:00   1:42 ./server_linux_amd64 -c /opt/kcptun/server-config.json
root       132  0.0  0.2   5428  1192 ?        Sl   16:00   0:00 ./server_linux_amd64 -c /opt/kcptun/server-config29905.json
root       133  0.0  0.8  11192  4688 ?        Sl   16:00   0:13 ./server_linux_amd64 -c /opt/kcptun/server-config29910.json
root       600  0.0  0.1 112600  1032 pts/0    S+   21:51   0:00 grep --color=auto server_
[root@localhost ~]# 
[root@localhost ~]# 

@xtaci
Copy link
Owner

xtaci commented Mar 9, 2017

kcptun-linux-386-20170309.tar.gz
kcptun-linux-amd64-20170309.tar.gz

试下这个吧,有个地方确实可能会延迟回收,但不清楚是不是这个原因。

@nylqd
Copy link

nylqd commented Mar 9, 2017

image
目前看来有改善

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

kcptun-linux-386-20170312.tar.gz
kcptun-linux-amd64-20170312.tar.gz

(fix json config 21:12)

@huawuxin 对,默认aes-256

@everfly 那就只能出杀手锏了, 这个增加了一个选项 -pprof 开启后,会监听 :6060端口,通过
http://IP:6060/debug/pprof/ 可以看到所有的内存使用情况。 我需要这个信息。

启动后,会提示

2017/03/12 12:58:59 pprof: true

@baggiogogo
Copy link

baggiogogo commented Mar 12, 2017

我这里也无法重现,观察了三天,连续剧十集1080连续看,vultr $2.5顶多16%内存占用,树莓派客户端就更少了,始终2%左右。

会不会系统也有关系,我的所有都是debian.

@everfly
Copy link

everfly commented Mar 12, 2017

@baggiogogo 我这边Linode, Bandwagon系统都是ubuntu 16.04LTS,然后两边内存占用都很高,不清楚是不是和系统有关系。。
@xtaci 配置文件里面添加“pprof”: true选项后,任然无法访问http://VPS_IP:6060/debug/pprof/,是需要安装其他什么嘛?nginx之类的?

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

@everfly 更新下,json配置刚才没有启用。

http://IP:6060/debug/pprof/heap?debug=1

heap的信息,所有内存分配状况:

# runtime.MemStats
# Alloc = 5330960
# TotalAlloc = 32008824
# Sys = 9804024
# Lookups = 130
# Mallocs = 425658
# Frees = 387148
# HeapAlloc = 5330960
# HeapSys = 6553600
# HeapIdle = 385024
# HeapInuse = 6168576
# HeapReleased = 0
# HeapObjects = 38510
# Stack = 786432 / 786432
# MSpan = 89680 / 98304
# MCache = 1200 / 16384
# BuckHashSys = 1446945
# GCSys = 458752
# OtherSys = 443607

@everfly
Copy link

everfly commented Mar 12, 2017

2017-03-12_211510
是重新启动的,无法访问

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

@everfly 重新下载一下#415 (comment)
要不就直接在命令行加 -pprof

@everfly
Copy link

everfly commented Mar 12, 2017

@xtaci 内容太多,debug info,你直接访问查看吧,不过这会儿才重开的kcptun,内存占用还很少。

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

# HeapAlloc = 6719968
# HeapSys = 12648448
# HeapIdle = 4194304
# HeapInuse = 8454144

目前看上去很正常,12M

@everfly
Copy link

everfly commented Mar 12, 2017

内存是缓慢上升的,需要播放个一个多小时后才能比较明显,好像是;
然后就是这个版本速度比较慢,不知道怎么的,管他的,反正测试,让它播放着吧
``
UPDATE 23:25 DEBUG INFO

# runtime.MemStats
# Alloc = 84640248
# TotalAlloc = 3737480176
# Sys = 126400824
# Lookups = 3244
# Mallocs = 58665673
# Frees = 58197224
# HeapAlloc = 84640248
# HeapSys = 113147904
# HeapIdle = 24748032
# HeapInuse = 88399872
# HeapReleased = 0
# HeapObjects = 468449
# Stack = 1146880 / 1146880
# MSpan = 1401288 / 1785856
# MCache = 1200 / 16384
# BuckHashSys = 1484945
# GCSys = 4825088
# OtherSys = 3993767
# NextGC = 113301744

debugInfo.txt

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

嗯,我一个小时后看heap信息

@xtaci
Copy link
Owner

xtaci commented Mar 12, 2017

观察到明天,看内存用量能否稳定。

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

kcptun-linux-386-20170313.tar.gz
kcptun-linux-amd64-20170313.tar.gz

@everfly 观察了一下,稳定到

# HeapSys = 139526144
# HeapIdle = 45727744
# HeapInuse = 93798400

139MB的堆使用

试下我的0313版本

@everfly
Copy link

everfly commented Mar 13, 2017

@xtaci

# HeapAlloc = 97027712
# HeapSys = 148733952
# HeapIdle = 45318144
# HeapInuse = 103415808

qq20170313-100733 2x

不是稳定在139MB,而是因为后来一直没有流量所以内存没有继续增加了,早上播放了一会儿就在继续往上走了。只要一直播放就会一直往上增加内存

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

@everfly 嗯,可以先替换到0313,另外,能否cat /proc/cpuinfo和 cat /proc/meminfo

@everfly
Copy link

everfly commented Mar 13, 2017

@xtaci 已更换0313,debug info已刷新可以直接访问查看

root@ubuntu:~# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 63
model name	: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
stepping	: 2
microcode	: 0x1
cpu MHz		: 2499.996
cache size	: 4096 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
bugs		:
bogomips	: 4999.99
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management:

root@ubuntu:~# cat /proc/meminfo 
MemTotal:        1013796 kB
MemFree:          206144 kB
MemAvailable:     559952 kB
Buffers:           31788 kB
Cached:           441984 kB
SwapCached:           36 kB
Active:           473220 kB
Inactive:         262360 kB
Active(anon):     248944 kB
Inactive(anon):    23852 kB
Active(file):     224276 kB
Inactive(file):   238508 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        262140 kB
SwapFree:         262008 kB
Dirty:                40 kB
Writeback:             0 kB
AnonPages:        193088 kB
Mapped:            30320 kB
Shmem:             10988 kB
Slab:              58052 kB
SReclaimable:      37388 kB
SUnreclaim:        20664 kB
KernelStack:        1932 kB
PageTables:         2956 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      769036 kB
Committed_AS:     347904 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:     32768 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       46968 kB
DirectMap2M:     1001472 kB
DirectMap1G:           0 kB

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

@everfly 好的,非常感谢,一个小时后观察。

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

# HeapSys = 14974976
# HeapIdle = 5824512
# HeapInuse = 9150464

目前看来正常,15MB

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

# HeapAlloc = 34002096
# HeapSys = 46465024
# HeapIdle = 10805248
# HeapInuse = 35659776

目前消耗 46MB @everfly 是否正常,一个小时过去了。

@everfly
Copy link

everfly commented Mar 13, 2017

暂时不在电脑前,中午看看,这个内存是慢慢增加的,所以这个是需要看趋势的。。。

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

kcptun-linux-386-20170313.tar.gz
kcptun-linux-amd64-20170313.tar.gz

这个是做过队列优化的,可以减少内存分配。可以试下。

之前版本的目前状况是:

# HeapAlloc = 55918056
# HeapSys = 77955072
# HeapIdle = 19046400
# HeapInuse = 58908672
# HeapReleased = 0

78MB

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

@everfly @huawuxin @BH4WHN @bettermanbao

最近的累积优化已经整理发布到0313 Release

如果还无法解决,可以通过设定GOGC有效的缓解。之前稳定在40MB的只是一种偶然的平衡,GC频率目前很低。

# NumGC = 175

提高GC频率,可以有效降低内存用量。

@huawuxin
Copy link

0303版开始的编译环境,跟0221版严格一致吗?有没有升级过编译器、或者修改过相关设置?

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

@huawuxin 一致的,golang 1.8 darwin/amd64,第三方依赖都是一致的。

hangim added a commit to hangim/kcp-shadowsocks-docker that referenced this issue Mar 13, 2017
@ghost
Copy link

ghost commented Mar 13, 2017

3月后的各版确实有BUG,我的是Bandwagon主机Centos 6 x86_64,1个G内存.
使用3月后的版本,128MB的SWAP经常性满占用.
另外还有个问题,用3月后的版本,在公司时Dropbox无法同步,以前是以为是公司网络封堵了UPD,没在意.
今天换回2月最后一版,马上就可以同步了,希望是个案.

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

@colalan 以0313版本为基础测试。

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

2017-03-13 5 35 23

这个是运行了5个小时的server端, 0313 Release, 内存25MB

@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

此贴先关,以0313版本为观察基础讨论此贴:#417

@xtaci xtaci closed this as completed Mar 13, 2017
@xtaci
Copy link
Owner

xtaci commented Mar 13, 2017

经过5天排查,真正内存泄漏原因疑似发现。
#417

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants