Sparkle Public Tracker 欢迎各位尝试测试

2908803755 · 2024年12月17日16:54

我可以现场架一个，然后你测测看

zhuxiaoying85309 · 2024年12月17日16:55

yum -y install unzip wget gcc zlib-devel make
wget https://github.com/1265578519/OpenTracker/archive/master.zip -O /root/OpenTracker.zip
unzip OpenTracker.zip
mv OpenTracker-master /home
cd /home
cd OpenTracker-master
cd libowfat
make
cd /home/OpenTracker-master
cd opentracker
make

你的操作系统需要使用0.33
rm -rf libowfat;mv libowfat-0.33 libowfat

2908803755 · 2024年12月17日17:06

编译过不去

gcc -c byte/byte_diff.c -pipe -W -Wall -Wextra -D_REENTRANT -O3 -I.
gcc -c byte/byte_equal_notimingattack.c -pipe -W -Wall -Wextra -D_REENTRANT -O3 -I.
gcc -c byte/byte_rchr.c -pipe -W -Wall -Wextra -D_REENTRANT -O3 -I.
gcc -c byte/byte_zero.c -pipe -W -Wall -Wextra -D_REENTRANT -O3 -I.
In file included from /usr/include/features.h:502,
from /usr/include/aarch64-linux-gnu/bits/libc-header-start.h:33,
from /usr/include/string.h:26,
from byte/byte_zero.c:2:
/usr/include/aarch64-linux-gnu/sys/cdefs.h:324:60: error: macro “__has_attribute” requires an identifier
324 | #if __GNUC_PREREQ (2,96) || __glibc_has_attribute (pure)
| ^
make: *** [GNUmakefile:179: byte_zero.o] Error 1

装了个系统的，现在可以了

2908803755 · 2024年12月17日17:09

我换好了，你再试试吧，现在是不经过 nginx 的，开销最小

2908803755 · 2024年12月17日17:10

端点和之前一样，不用做修改，我会看 stats 的

2908803755 · 2024年12月17日17:12

转发开始的话回复一下，我在这里短暂的挂一会儿 opentracker
感觉目前也就 200QPS 的样子

zhuxiaoying85309 · 2024年12月17日17:16

刚洗完澡，我来了，编译过不去是指libowfat吗，图上的报错信息不太完整
不过看起来你已经解决了，那我开始了

2908803755 · 2024年12月17日17:18

看起来是趴窝了，我这里已经打不开统计页面了

zhuxiaoying85309 · 2024年12月17日17:19

emmm难道真的是arm的机器性能上有问题

2908803755 · 2024年12月17日17:19

还有两个 vCPU 完全空闲

它不但趴了而且再起不能，现在我重启一下进程

我把流量切回主 Tracker 了

zhuxiaoying85309 · 2024年12月17日17:21

是，，，上面我写了，TCP上只能单核心处理数据，所以我也是分了两台服务器来跑的

你可以在同一个端口上，运行两个进程试试，这样会负载到2个进程上，不过peer会分散开

2908803755 · 2024年12月17日17:24

那我为什么不直接在 go 的 tracker 上把分片调大一点，而且还是在一起的……

zhuxiaoying85309 · 2024年12月17日17:26

那我先停调度了哦，事实证明，可能是arm机器本身有性能问题，你试试把外网TCP端口关闭访问
然后用ab测一下？
yum -y install httpd-tools

ab -n 100000 -c 100 "http://127.0.0.1/announce?info_hash=%2b%85%ee%8f%1d%c3u%c6%0e%14%a3WFB%c7%f4%a6%20M%c2&amp;peer_id=-UT354S-.%af%05%10%fb%e8J%95N%c0%c2%28&amp;port=22222&amp;uploaded=0&amp;downloaded=0&amp;left=0&amp;corrupt=0&amp;key=2BC15A17&amp;event=started&amp;numwant=200&amp;compact=1&amp;no_peer_id=1"

这是我的结果，符合1核心的CPU预期性能
Concurrency Level: 100
Time taken for tests: 7.310 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 17200000 bytes
HTML transferred: 10600000 bytes
Requests per second: 13680.35 [#/sec] (mean)
Time per request: 7.310 [ms] (mean)
Time per request: 0.073 [ms] (mean, across all concurrent requests)
Transfer rate: 2297.87 [Kbytes/sec] received

2908803755 · 2024年12月18日20:23

给后来的人提个醒，不要对着 80、443 上 NOTRACK，会直接导致 NAT 转换失效，结果就是 80、443 的出入站全部断网

jiangjinying18 · 2024年12月23日05:51

zhuxiaoying85309 · 2024年12月24日16:17

之前弄过几个免费的，感觉意义不大，一般2天或者一周就跑路了，还是付费比较踏实，服务器一个月十几块也不贵

2908803755 · 2025年01月11日15:33

解决了 SI 的问题了，再试试看？

排查到 SI 主要开销在 TCP 三次握手建联。不过我们前面有一层 CloudFlare，这种情况下可以利用 CloudFlare 的回源机制，让 Tengine 和 CloudFlare 的回源连接保持连接，避免大量连接频繁三次握手挤爆连接表和 SI。

分配一个巨大的 keepAliveTimeout 和 keepAliveRequests，尽量保证它们的连接不要中断。
背后把 Nginx 默认回源的 HTTP/1.0 换成 HTTP/1.1，加上 keepAlive，然后优先用 UDS，现在 SI 明显降低了。

我在 Sparkle Dashboard 的最底下新增了一栏 Sparkle Tracker 的指标，这样我就不用编辑帖子回复有关 QPS 的情况了。

可以通过切换左上角时间到 5 分钟并刷新来查看实时数据。

ce74412857059 · 2025年01月11日20:22

这是什么游戏？

zhuxiaoying85309 · 2025年01月11日23:45

CDN回源过程和源站保持keepAlive这个我不知道有没有作用
BT客户端都会使用http/1.0（天生短连接），或者通知tracker服务器close长连接
流量调度试了下确实比以前好了点的样子，至少没一直502烂掉，这个页面看起来也不是很灵敏的样子，感觉是arm天生偏弱或者系统原因
可以分析源ip一下会不会产生丢包现象，ping测一下邻居相邻的ip地址和网关是否会同时丢包，有可能是机房上层设备问题
这个qps发生突然的图表看起来更像是TPS（Transaction Per Second），而不是QPS（Queries Per Second）
大概维持在1000内没啥问题，我觉得已经极限了

参考
我这是活跃同时在线1500w用户，访问量确实太大了需要当时hz的cx11套餐至少2G内存才能容纳（这几年每几个月MarkScan这个机器人就DMCA要炸鱼一次，然后hz说不给放tracker了）
由于现在是毛子的1核心1G的vps，这还是经常内存不足杀进程重启，所以现在看到是500W用户（100w peer大约进程占用85MB内存）