可以可以，看看这次实际可以跑到多高的QPS
在试了，，目前看起来卡住了，提示503
5分钟，，19:07-19:13等会你报告里面看看数据吧，我猜是超过了5000上限。。
嗯，看起来是使用数据库的性能极限了
Java 对象有对象头的内存开支，所以只能用外部数据源，Redis 已经是相对好的选择了。
我觉得对 4C 的 ARM 处理器的小鸡要求不能太高了
后面可以换 Garnet 看看，但我不觉得能有非常明显的提升。
内存大的话，不知道直接把 meilisearch 当数据库来用会不会性能好一点
再试试看，我刚刚临时起了个 Garnet，现在切过来了，对比一下和 Redis 的性能差距
更新：重启了 Garnet，忘记改内存大小了
开始了，观察看看
看到 CPU 起来了，系统 CPU 占用在 40% 左右，还在观察
更新：当前 QPS 在 2.5k
我感觉服务器的带宽好像顶满了，我检查下
那我先关一下，居然宽带瓶颈了吗
刚刚 qps 峰值是 3.35k，CPU 在 88%，有一大批的异步响应管道刷写失败，应该是连接断了。
感觉带宽和 CPU 都有点瓶颈。
刚刚这一小会儿，传输了超过 20GB 压缩后的数据。你的 Tracker 服务器是怎么接下这一堆流量的？
Garnet 的性能似乎还真的是比 Redis/Valkey 好那么一点，但不排除是我心理作用。但目前可以先切换过来用，高负载的情况下 CPU 占用低一点，响应速度也快了不少。
我服务器不止一台，目前的话运行着2台服务器，每台tracker消耗在50Mbps-100Mbps左右
基本也是贴着CPU瓶颈走的，配置是1核心1G
你可以尝试优化内核试一下？是不是系统触发了1024限制导致失败，因为此时你的CPU并没有用满，可以参考文中方法优化下内核避免Linux的1024锁
https://bbs.itzmx.com/thread-18214-1-1.html
主要是这台服务器是跑整个 PBH-BTN 下面所有服务的，所以：
-
ulimit 现在是 unlimited，因为是自己写的程序，所以不太有打开文件数的担忧，而且现在的值已经非常高了
-
所有服务都被封装在 Docker 里保证安全性，我觉得 Docker 的网络驱动程序可能是有一定损失的
-
ksoftirqd 是有一点，内存碎片整理和也有点，但是同上考虑到安全性问题，防火墙还是得开着，因为没有外面其它防火墙挡着
-
现在 Garnet 不是最佳状态，因为没给它解除 memlock 的限制
-
opentracker 确实是专业的，极致的数据结构，精炼的代码，但是它没办法做更多的事情
ARM的机型确实单核性能差点意思
docker的网络是走iptables转发出去的，如果使用网络服务的话，就算设置为宿主机共享网络也一样，docker的确实性能会严重下降
ulimit 主要遇到过坑，centos以外的某些新系统，设置后不是真的解开1024限制了，需要另外修改一个文件来解开限制，得通过文中方法来确认是否修改成功，特别还运行在docker中可能修改方式更加不一样
可以试试看把JVM+其他服务的内存占用控制在系统内存的一半~四分之三，看看会不会有所改善
fs.file-max和fs.nr_open
可以看看7za跑分，单核心2000分就是正常的，不过二进制版本没有arm版本，得源码来编译
yum -y install glibc.i686 wget tar bzip2
wget --no-check-certificate https://downloads.sourceforge.net/project/p7zip/p7zip/16.02/p7zip_16.02_x86_linux_bin.tar.bz2 -O /root/p7zip_16.02_x86_linux_bin.tar.bz2
tar -xjvf p7zip_16.02_x86_linux_bin.tar.bz2
cd /root/p7zip_16.02/bin
./7za b
源码
wget --no-check-certificate https://downloads.sourceforge.net/project/p7zip/p7zip/16.02/p7zip_16.02_src_all.tar.bz2
tar -xjvf p7zip_16.02_src_all.tar.bz2
cd p7zip_16.02
make -j 4
make install