等于说流量被标记为pass绕过处理，降低了一些负载，比起完全关闭还是有差距
就我个人来说，是感受到一些变好的。
你可以再继续施加一下压力，我看看 5 分钟的 irq 情况，这次的时间比较短，可能队列并没有积压太多
量有点少，我看 irq 的进程没有什么压力，qps 只有刚刚 2k 的样子
Tracker 进程应该到瓶颈了 但是服务器目前网络还算正常，刚刚把 net.core.somaxconn 直接拉到 max 了
irqd 的 CPU 占用大概只有 5% 的样子，处于正常范围；和上次测试相比主要改进是
- Nginx（当然现在是 Tengine）不走 Docker 网络桥接了，直接使用 host 宿主机的网络
- 现在 Nginx 和 Tracker 程序通信使用 UDS （Unix Domain Socket），这直接就不走网络栈了而且速度飞快
- 我从 Tengine 项目官方复制了一下 Demo 的 sysctl 参数拿来用了
Tracker 的性能还有很大的优化空间
看起来现在好很多了，还需要加大量吗？
以前试过，没任何作用的一个参数
现在 nginx 还算能顶住，但是 Tracker 看着到瓶颈了。还得继续优化，明天看看高老师还有没有时间优化一下。
这个 Tracker 项目刚开了三天，要求不能太高。和开发了十多年的 opentracker 肯定没法比。
总感觉go语言挺垃圾的，跑不出什么高并发，至少我接触到的所有程序里面，没有遇到过一款go性能好的
可以用最好的c或者次一点的c++重写
opentracker也有个上限，由于没写更复杂的线程，在TCP上仅支持单核心cpu处理
根据CPU主频大小（2.5GHz-3.8GHz）支持每秒12000-20000左右请求
不过udp有实现支持多核心，只是tcp上只能单核心
Golang 挺不错的了，要在开发难度、运行速度和 RAM 占用之间取平衡，目前 Go 是首选
顺带一提虽然现在 ARM 生态不错，但和 amd64 还是有很大差距，很多硬件加速都不支持。
今晚有时间测试吗~
挂了个调试器上去，看看 pprof 性能报告
得稍微轻一点，nginx 打掉线了，pprof 也断开了
总感觉内核上不对劲，降低了。
是的，一些参数调低了，昨天调的太高了，一觉睡醒：
至于怎么导致的，暂且蒙在鼓里，撤销了一部分优化更改。
另外今天你访问其实是走的 HTTPS 回源，之前是 HTTP 回源。我是想用 CF 的 HTTP2 to Origin 来降低连接数的，但是 CF 一直焊死在 HTTP/1.1 上
我现在换成 HTTP 看看
图上是现在的数据？还是之前的？这流量不太对啊，70多w的并发，tracker没有这么大流量的，多半是有人攻击，全世界整个bt界就几千万人在活跃每天用bt
不知道 仅出现了一次，暂且不清楚具体原因，后面没再出现过了
压力测试是停止了吗，可以再上一些
HTTP 回源确实快了不少，不知道为什么 CloudFlare 在打开 HTTP2 to Origin 的开关下，即使 ALPN 正常，它也不愿意 HTTP2 回源。导致性能不如直接 80 好
还可以再加加
QPS 4200
pprof 文件顺利拿到了，可以暂停，我解析一下看看
刚刚你说降低，我现在调大一些
据我所知目前支持http2回源的web软件只有kangle（port加一个小写的sp，代表使用h2），但是试过感觉并不太行，也仅支持https的h2回源，不支持http的h2回源，还得后续更新
又加了一些调度，看起来服务端已经彻底boom了
瓶颈卡在 Syscall 上了，除了提升硬件基本是没办法了
cpu用尽了？系统调用瓶颈有可能是内核限制引起阻塞
比如遇到handle_accept等之类函数的调用阻塞就是明确的内核发生了限制
是，CPU 用尽了。乌龟壳的 OCI A1 是同等纸面参数下，性能最差的那一类，和同世代的 Intel/AMD 的性能差距能有六倍之多。
数据库、Tracker、Nginx 都在同一台设备上，负载挺高的。考虑到现在的稳定承载的 QPS 来说，我实在是不能对它要求过于苛刻了，毕竟性价比那是爆表的高。
那估计最高只能跑3000了，，稳定2000内正常运行。或者你可以搭建个opentracker测试一下看看能不能更高
opentracker 在处理 HTTP 方面要更差，纯暴力 select，它的表现不会比用了 epoll 等技术的 nertz 框架更好。
UDP 对于 BTN 来说没有意义，因为特征太少了。
opentracker在我的16元rmb的1核1G的服务器http性能表现为能稳定承载13000qps