光速到家，现在是20%了，如果没问题并且CPU负载很空闲的话，那性能方面就完美了
ip导致不合法指的是什么
负载绝对是起来了，但起来的不是 java，也不是 pgsql，是 CloudFlare Tunnel（cloudflared）。
现在瓶颈已经是 cloudflared 了，并发一高性能就这么差，估计后面得换掉。
ip导致不合法指的是什么
有的请求的里面加载着端口号(而且端口号是0)，但很少，不知道是哪个客户端宣告的不对劲
也许是因为其没有监听任何端口？
纯粹程序问题，因为任何时候，端口号都是独立于 IP 字段的
如果一个客户端没有监听任何端口 那端口字段会是什么呢？
不如用N2N
ip=xxxxx&port=0 或者 ip=xxxxx&port=1 (LibTorrent)
但绝对不是 ip=xxxxx:0
听起来像是CloudFlare Tunnel没有正确传递信息
我用 CloudFlare Tunnel 不是为了内网穿透，也不是组网，是为了隐藏服务端口暴露。
1個讚
绝大部分请求都没问题，我这里每个announce之类的操作都有审计日志用来 debug 和反吸血，等我拉一下看看。
@zhuxiaoying85309 我提议今天的测试可以先结束了，因为 cloudflare tunnel 程序已经顶不住了，我这里看到了一些 EOFException，应该是 tunnel 承载能力已经到极限了，再测试的话没有意义了。
我找个时间把 tunnel 换掉，直接回源吧。
格式都不对 确实是很可疑
我记得这个有带宽限制。
不知道现在是否还有时间调度流量呢？
我刚刚对 Tracker 做了异步队列优化，现在会在内存中缓存最多 5 秒然后再批量刷写到 DB。应该能提升性能。
做了一些修改：
- 现在 Announce 会在内存队列中缓存最多 5 秒，然后再批量（最多 512 个条目/批次）刷写数据库，能够有效提高性能。这同时也意味着不再占用 Async 线程池，也不会再宣告高峰时和 getPeersFromTorrent 争抢服务器性能。当然最重要的是阻止了对连接数的疯狂消耗，避免 Tracker 遇到数据库繁忙时挂掉。
- getPeersFromTorrent 操作现在有了一个 8 秒的超时。如果它没能在 8 秒内完成获取，操作会被放弃，并返回 Server is busy 消息，并通知客户端在晚些时候（现在是 1 分钟 ± 30秒）重试。
- 去掉了一些不必要的字段，减轻 DB 和程序负载（version, reqGeoIP 等）。
- 现在 announce 操作不再创建审计日志，因为发现压力太大了。
- 每次 announce 最多返回 <=100 个 Peers，减轻单次查询压力。
我来啦，，，在打游戏才看到消息，先10%流量吧，20%的话cf就爆了。。
cf 已经换掉了，现在是传统回源，无需担心 cloudflared 了。
目前负载 174qps，系统负载没动静。加压吧。可以直接上 30%
EDIT: 01:52 现在平均负载在 301qps，峰值 695qps
数据库挂了 我看下查询情况
EDIT: 01:58 增加了 DB 的内存可用量，还在观察。
很奇怪数据库的 CPU 没有上去，感觉哪里有奇怪的瓶颈。可能是 I/O。
设备最高 CPU 使用率大概在 50% 左右，远远没满。但是明显看得出来数据库没怎么动弹。
定位到问题了，正在修，异步搞砸了。
EDIT: 02:06 开始应用更改 更改已应用，应该能观察到 5xx 错误率开始下降
在 announce 的过程中用了个 future，导致启动了新的事务。大量新事务启动干没了所有数据库连接，应该修好了
先20%流量吧，在打着游戏不太方便操作，看看现在cpu负载怎么样
更改应用了，但是好像没有请求了？
看到请求了，并发太高了。
关掉了实验性的虚拟线程支持，现在看到服务开始恢复了。
平均 502 qps 1.01k qps，CPU 在 60-70% 左右，目前服务正常。
EDIT: 感觉多加 2GB 的 Heap 能再承载不少，重启服务器加内存。 3GB → 6GB
(服务重启进行中，重启完毕)
EDIT: 观察到 Peers 的持久化似乎出现了问题，在修改代码查看具体原因
开始应用修复，修复完成，现在 Peers 能够正常保存了。
由于不合理最大并发保存限制（本用于削峰，但现在全是峰），导致保存比产生快。现在暂时解除了这个限制。
等待流量调度，目前QPS 150。现在看来150qps是问题不大了。
异步刷写基本是瞬间就能刷写下来。
重启，加大线程数
打游戏的时候抽空改了下，现在60%流量调度
1個讚