Linux内测版

zhuxiaoying85309 · 2024年12月16日15:31

这是另一个分析工具，perf，得知v2.12.0版本引发CPU死循环的关键函数为sk_run_filter

Samples: 33K of event 'cycles', Event count (approx.): 5778034374                                                           
  Children      Self  Command    Shared Object        Symbol                                                                
+   85.76%     0.00%  bitcometd  [unknown]            [k] 0x0000000000000017
+   84.70%     0.00%  bitcometd  libc-2.31.so         [.] 0x00007f8c6799d68e
+   70.81%     0.15%  bitcometd  [kernel.kallsyms]    [k] tracesys
+   66.68%     0.36%  bitcometd  [kernel.kallsyms]    [k] syscall_trace_enter
+   65.62%     0.56%  bitcometd  [kernel.kallsyms]    [k] __secure_computing
+   64.84%     0.55%  bitcometd  [kernel.kallsyms]    [k] __seccomp_filter
+   58.51%    57.81%  bitcometd  [kernel.kallsyms]    [k] sk_run_filter
+    8.17%     0.00%  bitcometd  [unknown]            [.] 0000000000000000
+    6.36%     6.36%  bitcometd  [kernel.kallsyms]    [k] retint_userspace_restore_args
+    5.27%     0.00%  bitcometd  [unknown]            [.] 0x000001e805480789
+    5.27%     0.00%  bitcometd  bitcometd            [.] 0x00005600d3905240
+    4.88%     4.88%  bitcometd  [kernel.kallsyms]    [k] __x86_indirect_thunk_r8
+    3.67%     3.67%  bitcometd  [kernel.kallsyms]    [k] system_call_after_swapgs
+    2.43%     0.40%  bitcometd  [kernel.kallsyms]    [k] sys_epoll_wait
+    2.29%     2.29%  bitcometd  libc-2.31.so         [.] 0x000000000011f68e
+    1.94%     0.02%  bitcometd  [kernel.kallsyms]    [k] int_check_syscall_exit_work
+    1.94%     0.22%  bitcometd  [kernel.kallsyms]    [k] syscall_trace_leave
+    1.71%     0.00%  bitcometd  [unknown]            [.] 0xfbbdcf7705e15b00
+    1.66%     1.64%  bitcometd  [vdso]               [.] __vdso_gettimeofday
+    1.36%     0.76%  bitcometd  [kernel.kallsyms]    [k] __audit_syscall_exit
+    1.31%     0.00%  bitcometd  [unknown]            [.] 0x0000000000000001
+    1.24%     0.21%  bitcometd  [kernel.kallsyms]    [k] ep_poll
+    1.21%     0.00%  bitcometd  [unknown]            [.] 0xcde907894810c083
+    1.21%     0.00%  bitcometd  bitcometd            [.] 0x00005600d39e6280
+    1.15%     0.00%  bitcometd  bitcometd            [.] 0x00005600d39b597e
+    1.12%     1.12%  bitcometd  [kernel.kallsyms]    [k] seccomp_bpf_load
+    1.08%     0.02%  bitcometd  [kernel.kallsyms]    [k] apic_timer_interrupt
+    1.04%     0.01%  bitcometd  [kernel.kallsyms]    [k] smp_apic_timer_interrupt
+    1.03%     0.94%  bitcometd  [kernel.kallsyms]    [k] __audit_syscall_entry
+    0.97%     0.01%  bitcometd  [kernel.kallsyms]    [k] do_softirq
+    0.96%     0.00%  bitcometd  [kernel.kallsyms]    [k] call_softirq
+    0.87%     0.02%  bitcometd  [kernel.kallsyms]    [k] irq_exit
+    0.86%     0.01%  bitcometd  [kernel.kallsyms]    [k] __do_softirq
+    0.76%     0.00%  bitcometd  bitcometd            [.] 0x00005600d39e3019
+    0.74%     0.74%  bitcometd  bitcometd            [.] 0x0000000000989019
+    0.69%     0.00%  bitcometd  [unknown]            [.] 0x4800217f8010c083
+    0.69%     0.00%  bitcometd  bitcometd            [.] 0x00005600d39f0620
+    0.69%     0.00%  bitcometd  [unknown]            [.] 0x00005600d5ef78a0
+    0.66%     0.02%  bitcometd  [kernel.kallsyms]    [k] net_rx_action
+    0.64%     0.00%  bitcometd  [unknown]            [.] 0x0000004d0000002d
+    0.57%     0.56%  bitcometd  [kernel.kallsyms]    [k] _raw_spin_lock_irqsave
+    0.54%     0.54%  bitcometd  [kernel.kallsyms]    [k] fget_light
+    0.54%     0.00%  bitcometd  bitcometd            [.] 0x00005600d391349c
+    0.52%     0.01%  bitcometd  [kernel.kallsyms]    [k] virtnet_poll
     0.49%     0.00%  bitcometd  [kernel.kallsyms]    [k] __netif_receive_skb
     0.48%     0.04%  bitcometd  [kernel.kallsyms]    [k] __netif_receive_skb_core
     0.47%     0.00%  bitcometd  [unknown]            [.] 0x0000441f0f000000
     0.47%     0.01%  bitcometd  [kernel.kallsyms]    [k] local_apic_timer_interrupt
     0.47%     0.00%  bitcometd  [kernel.kallsyms]    [k] netif_receive_skb_internal

在 perf 分析结果中，sk_run_filter 占据了相当大的 CPU 使用量，这个函数通常用于网络数据包的过滤操作（如 BPF, Berkeley Packet Filter）。以下是几个可能的原因和建议：

可能的原因：

过滤规则复杂或数量多:
- 如果应用程序或系统在网络数据包过滤方面配置了大量或复杂的过滤规则，这可能导致高 CPU 使用。
高流量:
- 如果系统正在处理大量网络流量，特别是在高并发连接或数据包密集的情况下，会导致过滤器频繁调用。
次优的 BPF 程序:
- BPF 程序可能没有优化好，导致效率低下。

建议的措施：

优化过滤规则:
- 植入更加具体和简化的过滤规则，可能会减少 sk_run_filter 的开销。
分析网络负载:
- 使用网络分析工具（如 iftop、nethogs）查看当前的网络流量，识别是否有异常流量导致高负载。
BPF 程序优化:
- 查看和优化使用的 BPF 程序，通过减少复杂运算和指令可以提高性能。
更新内核/工具:
- 如果可能，检查内核更新和相关工具版本，以确保使用最新的优化和特性。

通过这些方法，你可以减少由 sk_run_filter 引起的 CPU 消耗。如果问题依然存在，可能需要更深入的分析，包括评估系统中运行的其他服务或应用程序的网络行为。

wxhere15 · 2024年12月17日03:41

用来配置docker版启动参数的。用命令行参数来中转比较麻烦

已经提交latest标签了

我是用wsl做开发，用虚拟机做测试

感谢反馈，我测试一下

zhuxiaoying85309 · 2024年12月17日10:31

对了，能不能帮我加个高级选项，bittorrent.sendfile
sendfile，直接调用系统api走内核级内存cache，不从进程读取数据，就和qb操作系统缓存类似，这样Linux下会存储缓存信息在buff/cache中，此时在iotop不会发生磁盘调用
$YN_9(J}CFIT{LK7(VW$UC5$

意思是
该选项默认值否，可选值是
启用该选项的设计实现为这样，不要写入的下载任务不走缓存了
http和BT下载任务依旧使用原有进程缓存
针对BT上传和长效种子，改为sendfile函数发起，使用系统级缓存这样在docker或者Linux与Windows下可以看到进程占用的内存会很小只有几十MB内存消耗

进程缓存有很大的优势
可以实现复杂的缓存策略，比如内容的有效期管理、清除策略等。而且可以在不同平台保持一致性，压缩、加密等操作时，进程缓存可以更好地支持复杂的协议处理，这些操作直接使用sendfile函数可能不太方便。

我认为应该有一个sendfile来调度系统缓存，现在有了无gui启动后，避免后续推广docker和Linux版本的时候，有人会嫌弃进程内存占用大，使用sendfile函数后，一切缓存由操作系统内核控制，自动进行cache，由于cache不是独占容易被其它程序冲刷掉，所以要写个提示告知用户启用后可能引发性能下降

或者默认值为是，可选值为否，下方注释提示关闭系统缓存后会提高性能
对于xp系统我不知道是否支持sendfile

wxhere15 · 2024年12月17日11:38

目前其实已经有3个内部调试选项了，分别控制是否启用系统的文件缓存、彗星自己的读缓存、写缓存。下一版可以开放出来

zhuxiaoying85309 · 2024年12月17日11:51

调度一定要用sendfile函数才行，这样才能减少上下文切换，不然调用系统性能会巨差
像我说的那样，写缓存不调用，只有读缓存才调用
还有启动后吃满CPU一个核心的原因找到了吗，CPU调试分析器上面看到很多???，因为符号被抹去了，看不完整

wxhere15 · 2024年12月18日03:11

查了一下资料，Windows下也有类似的API (TransmitFile) 提供 Zero Copy 操作。改动比较大，等下一版试试看吧

是wxWidgets 在Linux下控制台程序框架的问题，已做了临时修复

wxhere15 · 2024年12月18日05:45

bitcomet-webui docker版已更新至v2.12.1，修复了空载状态下CPU占用率高的问题

zhuxiaoying85309 · 2024年12月18日10:17

对，确认了，Windows下调度操作系统缓存这个叫TransmitFile，对应Linux的sendfile

我去测试下v2.12.1能不能正常下载磁力了，我猜估计就是这个CPU占用原因导致的一直卡住不进行下载

zhuxiaoying85309 · 2024年12月18日11:02

CPU占用正常了

但是依旧下载不了元数据。。。很诡异，进度一直是0%，应该还是有问题的，你那有复现吗，用种子链接也不行

手动上传torrent的话，http://ip:6080/api/task/bt/add 这个api就一直挂起未响应
用旧的api面板也不行 /panel/task_add_bt 一样处于挂起状态

这是我现在用的文件

services:
    sandbox:
        container_name: bitcomet-webui
        image: wxhere/bitcomet-webui:latest
        volumes:
            # mounts the host directory into the container to store config files
            - ./BitComet:/root/.config/BitComet:rw
            # mounts a host directory into the container to store downloaded files
            - ./Downloads:/root/Downloads:rw
        ports:
            # BitComet WebUI port
            - 6080:6080
            # BitTorrent ports
            - 6082:6082
            - 6082:6082/udp
        environment:
            - BITCOMET_WEBUI_PORT=6080
            - BITCOMET_BT_PORT=6082
            - WEBUI_USERNAME=admin
            - WEBUI_PASSWORD=itzmx.com

wxhere15 · 2024年12月18日11:16

我测试了磁链和种子文件链接，都可以下载。
magnet:?xt=urn:btih:IHTM2UGM5RK42VYEYXR5C5XHWWJRPI73&dn=ubuntu-24.04.1-live-server-amd64.iso
https://releases.ubuntu.com/24.04/ubuntu-24.04.1-live-server-amd64.iso.torrent

zhuxiaoying85309 · 2024年12月18日11:20

好像是bitcomet-webui无法主动发起本地连接，没有任何本地发起，只能远程接收
然后导致了建立连接成功后，docker无法发送我需要下载数据的网络数据包给对方peer，然后就无法下载了

我在做种机器删除了docker的ip地址，避免做种机器主动发起请求到docker，等待了很久docker都连不上做种机，docker里面显示做种机器的ip状态信息为dead[13|0|0]:25

docker统计页面显示Not Detected，不知道有没有关系

zhuxiaoying85309 · 2024年12月18日11:35

你这个种子倒是可以，但是自己做的种子就不行了，在Windows版下载是正常的，你试试做个种子，docker上就下载不了

magnet:?xt=urn:btih:XWZFQCN7Z4XGPJ6XGOXJ72WAFK5IOMJ3

然后我发现了一个内存泄漏好像，刚刚那个种子任务删除后，磁盘缓存当前是0，但是吃了900M内存一直不释放

你直接把种子文件下载到本地，然后点击选择文件上传，能不能复现我api卡住的情况？
https://dl.dmhy.org/2024/12/11/bdb25809bfcf2e67a7d733ae9feac02aba87313b.torrent

难道触发条件是只有特定的种子才出现？你快试试能不能复现。。
我这里测试十几个种子文件发现一些种子不行，一些可以，api无响应，可能是bitcomet-webui版本的符号处理出问题了

wxhere15 · 2024年12月18日12:18

我测试了一下，命令行版本webui在wsl下面可以下载这个磁链，在docker里面确实有问题……

zhuxiaoying85309 · 2024年12月18日12:22

那个vnc版本的一样有问题吗？还是问题只在bitcomet-webui的docker版本
那个vnc版本我服务器运行不起来，测试十几个种子，触发这个特定种子无法下载的bug概率大概在80%左右
直接纯Linux版本AppImage命令行模式启动我还没试过

ie12 · 2024年12月18日13:51

docker的话用的是什么网络模式呢？

zhuxiaoying85309 · 2024年12月18日13:55

这个bug和网络模式没关系，默认一般用bridge

ie12 · 2024年12月18日14:08

之前用noVNC的时候在桥接网络下 DHT似乎有问题
不知道后来修了没有如果可以最好试一下host模式
不过host模式 Win下不可用

zhuxiaoying85309 · 2024年12月18日14:22

刚刚用host模式启动试了，并不是这个原因，这是一个bug而已

ie12 · 2024年12月18日14:25

那可能是docker的问题看看能不能找个原生Linux测试一下 WSL也行

zhuxiaoying85309 · 2024年12月19日10:18

刚刚官方测试了，WSL上正常的，只有docker里面会发生问题，目前不知道是否两个docker版本都有问题
docker镜像底层换成centos试试？现在docker镜像底层系统是ubuntu 20.04.6 LTS，感觉这个系统太垃圾所以导致出来的docker有问题
或者这个docker镜像包是怎么做的，我做一个试试