zonyitoo

zonyitoo

Backend Developer

Member Since 10 years ago

Experience Points
888
follower
Lessons Completed
164
follow
Lessons Completed
1.4k
stars
Best Reply Awards
97
repos

791 contributions in the last year

Pinned
⚡ A Rust port of shadowsocks
⚡ H3C CLI Client for SYSU, which is implemented in C/C++. With an OpenWRT version.
⚡ INI file parser in Rust
⚡ Context utilities in Rust
Activity
Jan
20
6 days ago
push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

updated crypto2 for fixing aarch64 macro error

commit sha: 8ab8e296e064c76f09f54103e626e6c94ee404d3

push time in 6 days ago
push

zonyitoo push shadowsocks/crypto2

zonyitoo
zonyitoo

is_aarch64_feature_detected is a macro

commit sha: 4e983d4228152f8b8d6ed0d75e6b37627eec6a8e

push time in 6 days ago
push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

TCP tun poll_* may wake the same task when replacing waker

commit sha: 0306fa4f2f0deb7e93a3e9a862f914a476903a13

push time in 6 days ago
Activity icon
issue

zonyitoo issue spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

Activity icon
issue

zonyitoo issue comment spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

zonyitoo
zonyitoo

But still, the CPU usage is very high.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

High memory consumption for UDP associations on Linux (OpenWRT)

Test equipment: r4s Test system: openwrt

https://github.com/shadowsocks/shadowsocks-rust/suites/4952439929/artifacts/143776137 download:https://github.com/shadowsocks/shadowsocks-rust/actions/runs/1703977841

/etc/sysctl.d/11-nf-conntrack.conf

# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings

net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_max=1020000
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180

/root/socks/sslocal --protocol tun -s "[::1]:8388" -m "aes-256-gcm" -k "hello-kitty" --outbound-bind-interface lo --tun-interface-name tun1 -U --udp-timeout 60 --udp-max-associations 65535

dns.exe -sr gddx.txt -at google.com -sl 6

dns-test.zip

Start dns to test for 30 seconds, then shut down.

Then wait for 5 minutes, after the number of connections drops,

image image

Then it can be seen that sslocal occupies more than 400M of memory and will not continue to release,

zonyitoo
zonyitoo

This is the test locally in my virtual machine (x86_64):

Connecting to host 10.43.57.87, port 5201
[  4] local 10.255.0.1 port 34818 connected to 10.43.57.87 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  61.7 MBytes   517 Mbits/sec    0   88.4 KBytes
[  4]   1.00-2.00   sec  61.3 MBytes   514 Mbits/sec    0   88.4 KBytes
[  4]   2.00-3.00   sec  56.4 MBytes   473 Mbits/sec    0   88.4 KBytes
[  4]   3.00-4.00   sec  56.4 MBytes   473 Mbits/sec    0   88.4 KBytes
[  4]   4.00-5.00   sec  58.7 MBytes   493 Mbits/sec    0   88.4 KBytes
[  4]   5.00-6.00   sec  55.6 MBytes   466 Mbits/sec    0   88.4 KBytes
[  4]   6.00-7.00   sec  60.6 MBytes   509 Mbits/sec    0   88.4 KBytes
[  4]   7.00-8.00   sec  60.9 MBytes   510 Mbits/sec    0   88.4 KBytes
[  4]   8.00-9.00   sec  58.9 MBytes   494 Mbits/sec    0   88.4 KBytes
[  4]   9.00-10.00  sec  57.0 MBytes   478 Mbits/sec    0   88.4 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   587 MBytes   493 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   587 MBytes   492 Mbits/sec                  receiver

iperf Done.

Why your environment so special? :(

push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

updated crypto2 for fixing build on aarch64

commit sha: 58c78e03b8c56cd4a044d3b5f326334ff9fd7008

push time in 6 days ago
push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

upgrade shadowsocks-crypto/crypto2 for removing llvm_asm

  • crypto2 also supports dynamic code optimization path
  • fixes #749

commit sha: a8d87d7c475f0ed0b66139c1d0fa75d96649d670

push time in 6 days ago
Activity icon
issue

zonyitoo issue shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

Latest git code compilation failure.

error[E0635]: unknown feature `llvm_asm`
 --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/crypto2-0.1.2/src/lib.rs:2:21
  |
2 | #![feature(stdsimd, llvm_asm)]
  |                     ^^^^^^^^

For more information about this error, try `rustc --explain E0635`.
error: could not compile `crypto2` due to previous error
export RUSTFLAGS="-C target-cpu=native" && cargo +nightly build --release --features "stream-cipher" --features "local-redir" --features "local-dns" --features "jemalloc"

nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.60.0-nightly (5e57faa78 2022-01-19)
Activity icon
issue

zonyitoo issue comment spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

zonyitoo
zonyitoo

I was using an alternative way: https://github.com/shadowsocks/shadowsocks-rust/blob/4d30371bdf7b9c6eec2ab54ce4a042cfc82eac17/crates/shadowsocks-service/src/local/tun/tcp.rs#L225-L353

Every TcpConnection will have 2 RingBuffers and the main poll will copy all the data from/to every buffers in every single sockets. So we can avoid a huge lock for the whole system.

Activity icon
issue

zonyitoo issue spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

High memory consumption for UDP associations on Linux (OpenWRT)

Test equipment: r4s Test system: openwrt

https://github.com/shadowsocks/shadowsocks-rust/suites/4952439929/artifacts/143776137 download:https://github.com/shadowsocks/shadowsocks-rust/actions/runs/1703977841

/etc/sysctl.d/11-nf-conntrack.conf

# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings

net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_max=1020000
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180

/root/socks/sslocal --protocol tun -s "[::1]:8388" -m "aes-256-gcm" -k "hello-kitty" --outbound-bind-interface lo --tun-interface-name tun1 -U --udp-timeout 60 --udp-max-associations 65535

dns.exe -sr gddx.txt -at google.com -sl 6

dns-test.zip

Start dns to test for 30 seconds, then shut down.

Then wait for 5 minutes, after the number of connections drops,

image image

Then it can be seen that sslocal occupies more than 400M of memory and will not continue to release,

zonyitoo
zonyitoo

@f4nff Please test the latest commit and see if it solves this issue in your environment.

push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

copy send/recv buffer as much as possible

commit sha: 4d30371bdf7b9c6eec2ab54ce4a042cfc82eac17

push time in 6 days ago
Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

Latest git code compilation failure.

error[E0635]: unknown feature `llvm_asm`
 --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/crypto2-0.1.2/src/lib.rs:2:21
  |
2 | #![feature(stdsimd, llvm_asm)]
  |                     ^^^^^^^^

For more information about this error, try `rustc --explain E0635`.
error: could not compile `crypto2` due to previous error
export RUSTFLAGS="-C target-cpu=native" && cargo +nightly build --release --features "stream-cipher" --features "local-redir" --features "local-dns" --features "jemalloc"

nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.60.0-nightly (5e57faa78 2022-01-19)
zonyitoo
zonyitoo

Yes, use the Rust version recommended in rust-toolchain. It will be fixed later when crypto2 releases 2.0.

Jan
19
1 week ago
Activity icon
issue

zonyitoo issue comment spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

zonyitoo
zonyitoo

It shouldn't. You will have to take the lock of SocketSet when calling read, write and poll anyway, so there should be no difference.

Activity icon
issue

zonyitoo issue comment aramperes/onetun

zonyitoo
zonyitoo

Improve bandwidth

I tested some sftp tunneling on some big files and found that each connection is capped at around 2MB/s. Of course will depend on the latency and bandwidth with the WireGuard router, but with the kernel tunnel I get around 20MB/s for the same target.

$ sftp [email protected]
# 20MB/s

$ sftp -P 2222 [email protected]
# onetun: 2.4MB/s

Of course, getting parity with the kernel is not a goal since user space will be a bit slower, but I would like to aim for something like ~50% instead of ~10%.

zonyitoo
zonyitoo

Hello @aramperes , I may have encountered the same issue with smoltcp which have a lot smaller bandwidth than system network stack. Do you think the key problem is in smoltcp's design or there are any possible improvements could be done in application?

Activity icon
issue

zonyitoo issue comment spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is relatively slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

zonyitoo
zonyitoo

There are some projects out there:

  • embassy-net, which ​simply forbids multi-thread usage, so everything runs in a single thread (scheduler).

  • onetun, which make a global Bus (a broadcast channel) for dispatching events, like packets (send/recv), socket creation and destruction.

onetun's method may help to decoupling TcpStream and the poller (SocketAllocator), so every read and write won't require the global lock. I just did an experiment but performance drops even more (CPU usage goes higher).

push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo
zonyitoo
zonyitoo

EXPERIMENT: tun TCP separates read/write with interface poll

  • ref #745
  • reduce manager lock acquisition compete among TcpSockets and Interface::poll

commit sha: ada409f81a19ebc6fb26e9086180a46dfe403c68

push time in 1 week ago
Jan
18
1 week ago
Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

希望能接收信号以重载配置

举个例子: 我启动 ssserver 的时候加载了插件,我的启动命令是

ssserver \
  --server-addr 0.0.0.0:1 \
  --password password \
  --encrypt-method chacha20-ietf-poly1305 \
  --timeout 3600 \
  --udp-timeout 300 \
  --udp-max-associations 1024 \
  --nofile 1048576 \
  --tcp-keep-alive 300 \
  --tcp-fast-open \
  --tcp-no-delay \
  -U \
  --plugin "xray-plugin" \
  --plugin-opts "server;tls;fast-open;mode=grpc;host=xxx.domain.com"

这个插件加载了 SSL 证书,假设是免费的证书,有效期只有 3 个月,虽然我设置了 acme.sh 自动续期证书,但是要重启 ssserver 的进程才能让证书生效。

所以想问下 ssserver 能否增加接收某个信号来重启自身进程这个功能?就像 kill -SIGUSR1 <pid of ssserver>

zonyitoo
zonyitoo

Oh BTW, since you have set a crontab to call acme.sh, why not just kill the ssserver process and restart it after calling acme.sh?

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

希望能接收信号以重载配置

举个例子: 我启动 ssserver 的时候加载了插件,我的启动命令是

ssserver \
  --server-addr 0.0.0.0:1 \
  --password password \
  --encrypt-method chacha20-ietf-poly1305 \
  --timeout 3600 \
  --udp-timeout 300 \
  --udp-max-associations 1024 \
  --nofile 1048576 \
  --tcp-keep-alive 300 \
  --tcp-fast-open \
  --tcp-no-delay \
  -U \
  --plugin "xray-plugin" \
  --plugin-opts "server;tls;fast-open;mode=grpc;host=xxx.domain.com"

这个插件加载了 SSL 证书,假设是免费的证书,有效期只有 3 个月,虽然我设置了 acme.sh 自动续期证书,但是要重启 ssserver 的进程才能让证书生效。

所以想问下 ssserver 能否增加接收某个信号来重启自身进程这个功能?就像 kill -SIGUSR1 <pid of ssserver>

zonyitoo
zonyitoo

How about supervisord, which should be relatively smaller.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

希望能接收信号以重载配置

举个例子: 我启动 ssserver 的时候加载了插件,我的启动命令是

ssserver \
  --server-addr 0.0.0.0:1 \
  --password password \
  --encrypt-method chacha20-ietf-poly1305 \
  --timeout 3600 \
  --udp-timeout 300 \
  --udp-max-associations 1024 \
  --nofile 1048576 \
  --tcp-keep-alive 300 \
  --tcp-fast-open \
  --tcp-no-delay \
  -U \
  --plugin "xray-plugin" \
  --plugin-opts "server;tls;fast-open;mode=grpc;host=xxx.domain.com"

这个插件加载了 SSL 证书,假设是免费的证书,有效期只有 3 个月,虽然我设置了 acme.sh 自动续期证书,但是要重启 ssserver 的进程才能让证书生效。

所以想问下 ssserver 能否增加接收某个信号来重启自身进程这个功能?就像 kill -SIGUSR1 <pid of ssserver>

zonyitoo
zonyitoo

Well, you can always package any process managers you flavored in Dockerfile.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

希望能接收信号以重载配置

举个例子: 我启动 ssserver 的时候加载了插件,我的启动命令是

ssserver \
  --server-addr 0.0.0.0:1 \
  --password password \
  --encrypt-method chacha20-ietf-poly1305 \
  --timeout 3600 \
  --udp-timeout 300 \
  --udp-max-associations 1024 \
  --nofile 1048576 \
  --tcp-keep-alive 300 \
  --tcp-fast-open \
  --tcp-no-delay \
  -U \
  --plugin "xray-plugin" \
  --plugin-opts "server;tls;fast-open;mode=grpc;host=xxx.domain.com"

这个插件加载了 SSL 证书,假设是免费的证书,有效期只有 3 个月,虽然我设置了 acme.sh 自动续期证书,但是要重启 ssserver 的进程才能让证书生效。

所以想问下 ssserver 能否增加接收某个信号来重启自身进程这个功能?就像 kill -SIGUSR1 <pid of ssserver>

zonyitoo
zonyitoo

I am using process managers to fulfull the exact same goal. OpenWRT: procd, Linux: systemd.

Activity icon
issue

zonyitoo issue spacemeowx2/tokio-smoltcp

zonyitoo
zonyitoo

[Question] Performance issue in multi-thread runtime

I couldn't find another use cases in Github with tokio except yours.

I am working on a Project with also using smoltcp as an user space network stack and provide wrappers for interpolate with existed Tokio IO structs (TcpStream, ...), but I found some problems:

  1. Since Interface::poll requires to call frequently in a very short interval, it have to be put in a separated task (the Reactor in this Project).
  2. In the latest version of smoltcp, SocketSet is now managed by Interface, so if you want to call Interface::poll, and also AsyncRead::poll_read and AsyncRead::poll_write on TcpStream (wrapper of TcpSocket), you will have to take a lock on the Interface. (which is the same in this Project, the SocketAllocator).

I don't know if you have any benchmark data about the current design of tokio-smoltcp. I made a simple test with iperf3, which showed that the interface is a lot slower than system's network stack.

Here I open an issue and hoping you can share any informations about this with me.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

High memory consumption for UDP associations on Linux (OpenWRT)

Test equipment: r4s Test system: openwrt

https://github.com/shadowsocks/shadowsocks-rust/suites/4952439929/artifacts/143776137 download:https://github.com/shadowsocks/shadowsocks-rust/actions/runs/1703977841

/etc/sysctl.d/11-nf-conntrack.conf

# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings

net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_max=1020000
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180

/root/socks/sslocal --protocol tun -s "[::1]:8388" -m "aes-256-gcm" -k "hello-kitty" --outbound-bind-interface lo --tun-interface-name tun1 -U --udp-timeout 60 --udp-max-associations 65535

dns.exe -sr gddx.txt -at google.com -sl 6

dns-test.zip

Start dns to test for 30 seconds, then shut down.

Then wait for 5 minutes, after the number of connections drops,

image image

Then it can be seen that sslocal occupies more than 400M of memory and will not continue to release,

zonyitoo
zonyitoo

Except for tun, all the other local client interfaces have the same throughput as direct connections in a 1000M network.

Let me explain more about the current problems found in tun local:

  1. smoltcp requires a Virtual Interface structure to drive the state machine of all TCP sockets, so packets input / output have to be transferred to this virtual interface with channels (memory copies).
  2. smoltcp's Virtual Interface managers all the allocated sockets in one single structure and drive the state machines every time when poll was called. So if we want to use it in multi-thread program, we have to use Mutex to protect this interface, or manager. Every call of reads and writes have to take that lock first. poll must be called repeatedly in very short interval (in milliseconds).

But since my virtual machine only have 1 core, so all the tasks are now running in 1 thread, which means that they don't need to compete with each others about this lock. I don't want to make a conclusion that smoltcp can only run in that lower throughtput, so I will keep investigating.

If you have any thoughts about where is the bottleneck of the program, please comments.

Activity icon
issue

zonyitoo issue comment shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

High memory consumption for UDP associations on Linux (OpenWRT)

Test equipment: r4s Test system: openwrt

https://github.com/shadowsocks/shadowsocks-rust/suites/4952439929/artifacts/143776137 download:https://github.com/shadowsocks/shadowsocks-rust/actions/runs/1703977841

/etc/sysctl.d/11-nf-conntrack.conf

# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings

net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_max=1020000
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180

/root/socks/sslocal --protocol tun -s "[::1]:8388" -m "aes-256-gcm" -k "hello-kitty" --outbound-bind-interface lo --tun-interface-name tun1 -U --udp-timeout 60 --udp-max-associations 65535

dns.exe -sr gddx.txt -at google.com -sl 6

dns-test.zip

Start dns to test for 30 seconds, then shut down.

Then wait for 5 minutes, after the number of connections drops,

image image

Then it can be seen that sslocal occupies more than 400M of memory and will not continue to release,

zonyitoo
zonyitoo

You don't need to test every commits I made. I will tell you when it is ready for test. And you can stop mentioning tun2socks.

Jan
17
1 week ago
push

zonyitoo push shadowsocks/shadowsocks-rust

zonyitoo
zonyitoo

remove unnecessary yield in TCP manager's poll task

Tokio will handle dead loop properly.

commit sha: b4167b0addadfbdaeb5d25df7d4ba3ff22d34c0b

push time in 1 week ago