Freedom/Direct: use simple cache instead of map cache for UDP

[patterniha]

#4804 (comment)

[Fangliding]

起一万个这个map也才3~4MB内存 如果没有第一次写入底层数据结构不创建的话就只有650KB了 更别说这个map是会被回收的 图里的情况很明显和这个没有任何关系

[patterniha]

@Fangliding

I know, I didn't make this change because of RAM-problem, there is no need for map cache at all, because:

1. in "override.go" only initial fakeIP converted to domain, so we don't have multiple domain at all.
2. also, we don't have any use for multi-domain-cone (for example, in stun, only initial-request can be domain)
3. even if want to handle multi-domain, we should design reverse-lookup-map and handle it in read too.

so simple variable for holding initial-converted-IP is enough.

[Fangliding]

发往域的UDP请求可能被其他类型客户端发来 不管这是什么乱七八糟的情况 这只是让它不至于发生把后续目标为域的packet发到不同地方的这种离奇情况 它可能不基于回包IP跟踪 比如可能通过类似connection id的东西路由

真开始打架open reopen了 哎

[patterniha]

Which fight?

you closed this PR because you thought I did this for ram-problem, and I said the reason was something else, and reopen.

but now, you've given another reason, which is true, and I close this PR base on it.

I have no problem with you, I am a patient person, I hope you stop talking to me in this tone.

[kastov]

@patterniha any ideas of cause memory leak on version above 25.7.x?

[Fangliding]

don't guess, get a pprof profile

[patterniha]

@patterniha any ideas of cause memory leak on version above 25.7.x?

For which configuration? send client/server config.

[kastov]

@patterniha any ideas of cause memory leak on version above 25.7.x?

For which configuration? send client/server config.

I will return with a few days with heap/alloc dumps.

Server and client config is simple: trojan+tls and vless+tls. simple (basic) dns, no any hard routing.

And yes, it is definitely something which occurs only on the 25.7.x or 25.8.x versions, 25.6.x was ran for a month with no issues

[kastov]

@patterniha @Fangliding

Current ram usage: 3.2GB (according to btop)

heap+gor+allocs.zip

debug/vars

Count	Profile
4403	[allocs]
67934	[goroutine]
4403	[heap]
16	[threadcreate]

    "Alloc": 2100572976,
    "TotalAlloc": 6109575889928,
    "Sys": 3412487768,
    "Lookups": 0,
    "Mallocs": 23604361986,
    "Frees": 23598127458,
    "HeapAlloc": 2100572976,
    "HeapSys": 2522710016,
    "HeapIdle": 306298880,
    "HeapInuse": 2216411136,
    "HeapReleased": 3121152,
    "HeapObjects": 6234528,
    "StackInuse": 786595840,
    "StackSys": 786595840,
    "MSpanInuse": 45908320,
    "MSpanSys": 51881280,
    "MCacheInuse": 9664,
    "MCacheSys": 15704,
    "BuckHashSys": 2591497,
    "GCSys": 25739880,
    "OtherSys": 22953551,
    "NextGC": 2506993522,
    "LastGC": 1.7558738906107945e+18,
    "PauseTotalNs": 1343780393,
    "NumGC": 10353,
    "NumForcedGC": 3,
    "GCCPUFraction": 0.00379500644127423,
    "EnableGC": true,
    "DebugGC": false,
    ```
    

</p>
</details> 

[Fangliding]

给出实际使用的xray的平台和版本号(官方版本)

[kastov]

Give the platform and version number of xray actually used (official version)

25.8.3 (xray-linux-64), release

Xray 25.8.3 (Xray, Penetrates Everything.) bd86732 (go1.24.5 linux/amd64)

Runned on: host machine: Ubuntu 22.04, docker container: alpine linux

[Fangliding]

再跑一段时间等内存占用更高了再发个看看吧 暂时没看出啥问题很大的地方 就是有很多的Trojan uot请求而已 不过这些东西一般都会被回收的不会被泄露

[patterniha]

One of the suspicious cases is udp-dispatcher, although i didn't find any big problem with it's code, and I don't think the problem is because of that, but it is complicated and not optimized, for example there is no need to create connEntry struct twice:

Xray-core/transport/internet/udp/dispatcher.go

Line 69 in 33272a0

entry := &connEntry{}

Xray-core/transport/internet/udp/dispatcher.go

Line 86 in 33272a0

*entry = connEntry{

or for closing connEntry there is no need to check whether it is v.conn or not, and the logic is not correct.

i simplified and optimized it: #5050, it is just simplification and optimization, and probably have nothing to do with this problem.

///

***also, after closing connEntry, it's timer was still active and was not canceled, and i fix that.

[patterniha]

I think, i found the main problem:

after creating new buffer, for each received UDP-data (for example in freedom), we should release it after sending it to the client.

we released it in socks and shadowsocks correctly, but we didn't release it in trojan and udp_nameserver.

i fix it in: 83ba3c3

@kastov test main-branch + #5046 + #5050, the memory leak problem should be solved.