内存慢慢泄露

[ivanszl]

Bug Description

在客户端经常性断开重连和每天产生很多动态客户端连接的时候，会出现内存慢慢增加的情况
整体如下图所示

查了下代码可能是在
pkg/nathole/nathole.go
这个代码里

		xl.Debugf("get udp message local %s, from %s", conn.LocalAddr(), raddr)
		var m msg.NatHoleSid
		if err := DecodeMessageInto(buf[:n], key, &m); err != nil {
			xl.Warnf("decode sid message error: %v", err)
			continue
		}
		pool.PutBuf(buf)

调整为如下是否可以避免

		xl.Debugf("get udp message local %s, from %s", conn.LocalAddr(), raddr)
		var m msg.NatHoleSid
		if err := DecodeMessageInto(buf[:n], key, &m); err != nil {
			xl.Warnf("decode sid message error: %v", err)
                         pool.PutBuf(buf)
			continue
		}
		pool.PutBuf(buf)

frpc Version

0.54.0

frps Version

0.54.0

System Architecture

linux/amd64

Configurations

bindPort = 8000

vhostHTTPPort = 8090
auth.method = "token"
auth.token = "****"

[[httpPlugins]]
name = "notify"
addr = "127.0.0.1:18081"
path = "/s/handler"
ops = ["NewProxy", "CloseProxy"]

Logs

No response

Steps to reproduce

...

Affected area

• Docs
• Installation
• Performance and Scalability
• Security
• User Experience
• Test and Release
• Developer Infrastructure
• Client Plugin
• Server Plugin
• Extensions
• Others

[fatedier]

1. 使用最新版本。
2. 你贴的代码不相关，设计机制如此，小概率发生的 case 不主动将 buffer 放回缓存池，会被 gc 掉。
3. 分析内存尽量用 linux 下专业的工具获取完整的信息，你贴的截图甚至连纵坐标是什么都没有，很难就此沟通。

[ivanszl]

这个是 30 天的frps 的 metrics 数据

代码块那里看到的是使用了内存池的模式，如果出现 decode 失败后，就会一直分配着不释放了

[fatedier]

memory 有很多种，尽量用工具调试观测吧，我没有太多精力和你深入讨论这里面的技术细节。

[wuai1024]

我看了下我的 frps，目前监控数据如下（没有发现内存异常问题）：

客户端很多 frpc 在使用

流量使用也算还可以吧

[ivanszl]

我看了下我的 frps，目前监控数据如下（没有发现内存异常问题）：

客户端很多 frpc 在使用

流量使用也算还可以吧

我这边使用场景是客户端比较频繁的更换，频繁的上下线，更换了版本后还是会慢慢的增长

[wuai1024]

我这边使用场景是客户端比较频繁的更换，频繁的上下线，更换了版本后还是会慢慢的增长

你应该是看错了指标， frps 的 metrics 数据中有多个内存指标。

1.process_resident_memory_bytes: 这是进程的常驻内存大小，以字节为单位。你的数据是 6.168576e+07 字节（约 61.7 MB）。这表示当前进程正在使用的物理内存。

2.process_start_time_seconds: 这是进程启动的时间，自 Unix 纪元（1970年1月1日）以来的秒数。你的数据是 1.72957623554e+09，可以通过将其转换为可读的日期时间格式来了解进程何时启动。

3.process_virtual_memory_bytes: 这是进程的虚拟内存大小，以字节为单位。你的数据是 1.276801024e+09 字节（约 1.28 GB）。虚拟内存是进程可用的内存总量，包括物理内存和磁盘交换空间。

4.process_virtual_memory_max_bytes: 这是进程可以使用的最大虚拟内存量，以字节为单位。你的数据是 1.8446744073709552e+19 字节（约 18.4 EB）。这通常表示理论上的最大值，实际使用可能会受到系统配置的限制。

你可以看看，参考下。

[ivanszl]

我这边使用场景是客户端比较频繁的更换，频繁的上下线，更换了版本后还是会慢慢的增长

你应该是看错了指标， frps 的 metrics 数据中有多个内存指标。

1.process_resident_memory_bytes: 这是进程的常驻内存大小，以字节为单位。你的数据是 6.168576e+07 字节（约 61.7 MB）。这表示当前进程正在使用的物理内存。
2.process_start_time_seconds: 这是进程启动的时间，自 Unix 纪元（1970年1月1日）以来的秒数。你的数据是 1.72957623554e+09，可以通过将其转换为可读的日期时间格式来了解进程何时启动。
3.process_virtual_memory_bytes: 这是进程的虚拟内存大小，以字节为单位。你的数据是 1.276801024e+09 字节（约 1.28 GB）。虚拟内存是进程可用的内存总量，包括物理内存和磁盘交换空间。
4.process_virtual_memory_max_bytes: 这是进程可以使用的最大虚拟内存量，以字节为单位。你的数据是 1.8446744073709552e+19 字节（约 18.4 EB）。这通常表示理论上的最大值，实际使用可能会受到系统配置的限制。

你可以看看，参考下。
会有所偏差，但是整体差不多，主要是被系统 kill 后也查系统日志，被 kill 是内存占用确实也挺高的

日常连接使用如下图所示

程序占用内存如下图所示

[wuai1024]

用不了，格式不对，你发json 文件吧

[ivanszl]

用不了，格式不对，你发json 文件吧

我是用这个 20370 ID 导入的，你试试看看

[wuai1024]

用不了，格式不对，你发json 文件吧

我是用这个 20370 ID 导入的，你试试看看

我也是用的这个，没有你那几个内存显示

[ivanszl]

用不了，格式不对，你发json 文件吧

我是用这个 20370 ID 导入的，你试试看看

我也是用的这个，没有你那几个内存显示

frps.json

[ivanszl]

用不了，格式不对，你发json 文件吧

我是用这个 20370 ID 导入的，你试试看看

我也是用的这个，没有你那几个内存显示

进程内存的两条线分别为：
process_resident_memory_bytes{instance=~"^($NODE)$"}
process_virtual_memory_bytes{instance=~"^($NODE)$"}

[wuai1024]

我的是这样的

[ivanszl]

我的是这样的

另一个稳定客户端连接内存也是很稳定，就只有在频繁端开，连接，实例名称是动态的会有问题
多谢，我这边再看看