内核参数都改了的话，可能是系统有问题，不像centos系统一样能够适合稳定的高并发
或者像帖子上那个案例，，，在大便12系统上改了，以为改好了，但是实际上没改成功，因为这个系统的修改方式不一样，导致内核没起效果
现在在看内核告警，有点告警需要检查，然后明天看下 HTTP2 的问题，CloudFlare 打过来的感觉还是 HTTP/1.1
还得再降一半，至少保证 Tracker 能正常工作的样子，现在内部网络好了一点，但还是不稳定
好了，又降低了，奇怪了，2个小时前改成os线程那时候不是挺正常的吗
要不然你停一下，我检查一下软中断？
停了，，你看看降下来了吗？
降了接近 20%+ 的 si
让高老师帮忙用 Golang 糊了个新的 Tracker，试试看吧！ @zhuxiaoying85309
地址是：https://sparkle.ghostchu-services.top/announce
服务器没换，用 CloudFlare 重定向到了新的端口上，现在默认基底是 966 QPS。
只调度了部分流量过去，目前看还可以，请求响应时间在10s左右
有些延迟，请求很大程度上容易超过5秒，估计已经队列阻塞了
目前看到缺少完成信息返回值，导致数据不显示，其它是否能正确获取ip之类的还没去测
1個讚
QPS 是 2,900 考虑到本来就有接近 1000 的 QPS 是 Sparkle 自己的，大概调度过来 1900 的样子
单机 3000 qps 感觉挺极限了
CPU 没吃满，数据结构还能优化
@zhuxiaoying85309 数据结构改进完了，可以再试试看看
现在可以看看
看到 2.5k 的 QPS，tracker 程序目前压力良好，但是 ksoftirqd 已经爆了，我去看看禁用 netfilter
dockerd 开销也非常大，可能是负责端口转发导致的
流量麻烦再给一会儿（
给 nginx 换了个 host
现在还在转发吗
刚才tracker一直连不上
刚降低了一点调度，调高回去了，你在看看
看到了接近 3000 的 qps，换到 host 之后 dockerd 和 irq 似乎都有所下降
可以先暂停一下，我现在把 nginx 挪到外面来，然后看看关掉防火墙
docker性能很差，确实不适合跑网络，就算改成host模式也不太行，帖子上面我有说过。。。那些CPU计算消耗都是无意义的
嗯，，之前10秒左右响应，从图上看到现在3秒左右响应，确实快多了，虽然应该还有很大的优化空间，你这CPU配置对应跑个8wqps没啥压力才是