应该是和我测试版这贴之前说的，长效种子用的是CPU主线程，和界面跑到一起去了，然后就会变卡
BT传输也是主线程。。然后就卡了
电量消耗啊，，盲猜DHT引起的
在HTTP任务属性窗口里有的，找找看
目前长效种子上传的大部分操作确实还在主线程完成，如果改成其他线程操作估计可以避免卡顿。后续版本优化
谢谢反馈，下一版修复
谢谢反馈。请问您的CPU型号？BitComet运行的任务数量？平均上传、下载速度？是否开启了DHT、长效种子、种子市场、DHT种子列表、种子列表自动下载元数据等功能？
我的cpu是i5-4590，win7系統，
BitComet運行通常不會超過2個，
平常時段只上傳，在睡前才會下載，
滿載上傳1.8M，下載350K，
DHT開啟，長效種子開啟，種子市場開啟，
"种子列表自动下载元数据"←這是甚麼功能?怎麼找不到！
沒有使用驢子，沒有啟用防毒掃描，
我目前的BC設定已經延續很多版，
歷經很久.很久…很久…很多年很多年很多年都沒有變動，
唯一變動的！只有在近期插滿32g記憶體開了16g給BC做緩衝，
我也試過開小點記憶體緩衝1G/4G/8G/12G，問題依然存在，
以前單純掛BC通常就是落在40w正負3w間跳動，
40w很能接受，也就這麼掛了很多年，
現在單掛BC的瓦數就是4x~6x間跳動，
這現象是近幾個禮拜在睡前掛BC時無意間因為風扇聲比較明顯，
進而開工作管理員才發現，怎麼會單單只掛BC，處理器要吃掉2x%才驚覺不對勁，
觀察程序頁面發現單掛BC，程序nt kernel & system會立即拉高占用率，
處理器就會連同BC程序一共被吃掉20~25%左右的使用率，耗電量也就飆升，
一關BC處理器使用率就恢復正常低負載，實在不知道該怎麼辦…
这个system进程变高我之前有出现提交过，，不过后来又没出现过了，可能当时用的vps服务器配置太差了
具体因素不知道，不过和每秒UDP发起有挂钩，为了省电你可以你进高级设置改一下试试。默认值1000，尝试改小点，例如修改为8（如果这个数值过小时请禁用DHT，，因为UDPtracker就能拉满并发了），然后在统计分类可以看到当前的运行情况
network.max_udp_pkt_per_sec
找到此处，下拉即可看到
| UDP Transfer | recv[26.1 GB]: 186 KB/s, send[27.9 GB] 102 KB/s |
|---|---|
| packets recv[111,703,880]: 488 pkt/s, send[162,397,380] 1026 pkt/s | |
| queue recv: 0, send: 102,700 | |
| DHT | recv[25.9 GB]: 186 KB/s, send[16.9 GB] 265 KB/s |
| packets recv: 108,479,327, send: 149,371,679 | |
| queue send: 102,700, threshold: 30,000, dropped queries: 343,796 | |
| UDP tracker | recv[34.1 MB]: 0 KB/s, send[110.1 MB] 0 KB/s |
| packets recv: 949,405, send: 1,529,665 | |
| queue send: 0 |
顺便，，，20分钟一次任务间隔主动更新DHT tracker的时候，不会受到threshold限制进行dropped
utorrent这个功能视乎不错，，可以做一份
總感覺 udp 已被 isp & 一隻看不見的手 干擾, 從彗星用戶長效 udp 互傳, 就可看出速度只有幾10k 慘淡情形…
建議以下這些, 改成支援 udp / tcp 雙模…
如長效已經有了… 好像還缺 tracker, dht 可以從進階選項設置
这个选项在左侧列表种子市场节点右键菜单里，默认关闭。您的截图里已经出现了。
如果方便的话，您可以切换到旧版测试一下，帮忙分析一下从哪个版本开始出现CPU占用飙升的现象，感谢您
您的任务列表有五千多个任务，也可能会有影响。您可以用文件菜单里的任务导出功能先做个备份，然后把旧任务暂时删除掉（可保留已下载的文件），看看是否有改善。测试完成后如有需要可以重新导入之前的几千个旧任务。
已下载的元数据BitComet界面上没有菜单命令去清除。如果您确实想清理，可以手工清除 ：%appdata%/bitcomet/torrent_cache/
感谢建议，可以增加这个“启用UDP Tracker支持”的选项。另外方便的话，麻烦看看DHT开启后UDP数据包发送队列过长的现象新版是否有了明显改善，谢谢啦
依照zhuxiaoying85309的建議，
調低network.max_udp_pkt_per_sec數值1000→8後確實能夠將處理器佔用率降低，
但最高也會有10~15%間跳動，還是明顯的偏高許多，
我印象中之前單掛BC處理器的使用率大多維持在3%上下，
而調低network.max_udp_pkt_per_sec數值後，
功耗計顯示的數值也比較常態的維持在43瓦上下跳動，
但還是會有5x~6x，甚至7x的數值出現，出現的頻率不算低…
我是個有新版就會更新到最新版，舊版我再找時間試吧…
不知道這個處理器佔用率偏高的狀況是維持了多少版本去了…
我印象中，拿功率計測耗電瓦數是2~3年多前了…
要不是那天在睡前關掉所有程式單掛BC，連螢幕也關掉的情況下，
還能聽到明顯的風扇運轉聲響，覺得怪怪的不對勁，
於是又打開螢幕看工作管理員的處理器一直在2x%起伏才發現，
不然還真不知道要繼續浪費多少電…
在流量图页面右键菜单选择CPU占用率，可以看到是否为UDP处理线程占用CPU过高。
您可以搜索并下载 Intel Power Gadget 实时显示CPU功率。
您可以从以下网址下载旧版安装包： https://download.bitcomet.com/achive/ 多个版本装到不同的目录，每次启动其中一个，方便比较
截图还是看不到啊，能不能解决下？
总显示“程序无法显示页面”，影响选片。
据我所知，这种情况一般是校园网，或者移动宽带，少部分是电信宽带
任务更新的时候，DHT要不要考虑下进行队列丢弃限制啊，现在代码没考虑到，一更新，就会产生十几万的包队列等待发送。
还以为是DHT节点数量太多了，有好几万的DHT节点数量，我把软件退了重新打开，DHT节点数量降低到1800后，更新一次居然也还是发送十几万的包。
这些包具体是什么内容呢？
就是询问DHT节点查询对方有没有正在下载这个任务，有的话就加进去peer用户列表啊，和tracker一个道理
有时候还是会有一些端口号读不出来，看peer ID应该是手机版迅雷发出来的远程连入
后来发现是云盘离线下载服务器发起的，transmission可以正常显示端口号
迅雷云盘服务器，开始使用libtorrent 1.1.6版本进行离线下载了
1個讚
端口号读不出来我也经常遇到
