download-manager
download-manager copied to clipboard
CPU占用过高问题 【High CPU usage problem】
最近有一些人反应插件在下载文件时,出现CPU占用100%的情况。
可能我这边测试用的机子性能比较好,没有出现过100%占用的问题,甚至20%的情况都没有。
后续我找一些性能低一些的机子测试下。
性能优化持续进行中
相关的issues: #42 #40
本人使用机器是intel Xeon E3-1230V5 16GB DDR4 SATA3 SSD。 一样出现这个问题,基本100%复现。这个问题是最近才出现的。 现象就是开始下载后会直接CPU 100%卡死,出现大量线程,需下载完成后等待一段时间才能恢复。如有需要,稍后可补截图。
正常:
下载时:
@steveyan00 你电脑上有开启windows defender吗?或者就只是360
@steveyan00 你电脑上有开启windows defender吗?或者就只是360
windows defender 有开启,360是浏览器插件,本体是关闭的,防护用的是火绒。
@steveyan00 你电脑上有开启windows defender吗?或者就只是360
windows defender 有开启,360是浏览器插件,本体是关闭的,防护用的是火绒。
好的,情况已经收到,最近我会认真研究下,争取早点解决问题
@steveyan00 你电脑上有开启windows defender吗?或者就只是360
windows defender 有开启,360是浏览器插件,本体是关闭的,防护用的是火绒。
好的,情况已经收到,最近我会认真研究下,争取早点解决问题
感谢你的杰出作品。
另,我的浏览器版本是
我也是火绒,一样的问题
![Snipaste_2020-09-12_12-37-00](https://user-images.githubusercontent.com/45061254/92987514-a9bb2300-f4f5-11ea-89bc-1a77dc946d4d.png)
![Snipaste_2020-09-12_12-37-12](https://user-images.githubusercontent.com/45061254/92987517-ade74080-f4f5-11ea-9b36-a22e0b1ad5c5.png)
最新测试发现,将下载列表历史记录清除,不会产生很多线程,cpu正常
最新测试发现,将下载列表历史记录清除,不会产生很多线程,cpu正常
果然清空列表就正常了! 我觉得和机器性能没什么关系, 我是I7-9700, 64G内存, SSD, 在清空列表前照样卡死... 清空列表以后虽然不卡了, 但是在一开始速度毕竟快, 过几秒就下载速度奇慢无比.
看来不止我遇到了,弹出保存框的时候就开始了(因为预下载机制),特意找了个大文件来下载,确实是持续100%,并非只要开始的时候
只要下载文件,在资源管理器中看到Edge不停的创建新的进程,成百上千,CPU100%。 禁用插件后恢复正常。 这跟电脑配置高低没什么关系了(现在的机器性能都不差吧,开个浏览器不会有问题)。大规模反馈这个问题了。很多人不知道这个渠道,或者不知道哪里出现了问题,我也是找了很久才发现是这个插件的问题。 目前使用最新的Edge浏览器。
如图,创建了1444个进程,2000多的也有,系统卡死,无法截图。
同楼上老哥说的,清空列表后没有出现 cpu 跑满的问题
嗯!清空列表后正常了,不然一下载东西就是100%
原来如此, 我是个开着Windows defender的chrome用户, 今天也遇到了这个问题, 不得不卸载插件了, 也不知道这么多天过去了目前有没有办法解决. 还没办法的话, 我倒是有一个思路, 为什么不清理下载列表会慢, 是不是因为插件会默认把一整个下载列表都读进GUI里, 导致变得很占CPU的, 如果是的话, 可以尝试分页, 只有用户需要浏览到很久的下载列表, 再加载剩下的列表
试了一下下载一个小文档cpu占用40%,关了这个下载基本不增加cpu占用
终于&完全 确认了该问题的根源.
@xinghaix 希望有助于彻底修复致命性能问题 带来灵感!
🗣 在 2个不同浏览器 (Chrome86、Chrome83) 都能出现问题, 测试验证过, 因此提供给作者!
请注意, 大文件下载没啥问题, 问题都是出在批量小文件的下载时 (其单文件能够瞬间完成的)
如何100%重现 ❓
- 要重现此类性能问题, 很简单: 一次性批量下载N多小文件 ,并且启用通知 image
- (⚠小文件也必须是瞬间能下完的小文件, 大文件应该没啥问题)
- 小文件, 如
几百kb
内 的图标图片、几㎆
内 (总之单个小文件能瞬间下载完毕的)
- 小文件, 如
- 🗣请注意: 所有批量小文件, 必须至少能够紧挨着进行/同时进行/或至少是毫秒/秒内的持续下载.
- 若找不到小文件, 这里提供批处理, 一键生成N多小文件 (改动
300
即生成的个数)
- (⚠小文件也必须是瞬间能下完的小文件, 大文件应该没啥问题)
@echo off
echo 正在创建test1.txt~test11.txt......
for /l %%i in (1, 1, 300) do (
echo 我是批量小文件%%i.txt文件的内容 >> 批量小文件%%i.txt
)
echo 文件创建完毕
带来什么问题 ❓
-
问题1: 插件自身线程堵死 , 表现为: ↴
- 通知 瞬间同时并发.
- 通知 占满整个窗口高度 (应该像其它插件那样,最多出现3个才好)
- 通知 的动作栏(打开文件/文件夹) 无法点击
- (由于一直弹出通知, 因此也就无法点击展开动作栏)
-
问题2: 没多久就会导致下载链(URL)假死 , 即终止下载响应.
- 具体为: 前几个小文件下载成功后, 后面的无论如何都无法继续下载了...
- 下载大文件, 没问题, 猜测是插件有足够时间来逻辑处理.
- 批量下载小文件, 导致假死/卡死/不能继续下载的问题, 猜测是由于插件来不及逻辑处理.
- 要想继续下载, 唯一的解决是 关闭插件,
- 关闭插件若也无解, 则必须重启浏览器并先关闭插件, 才能完成批量下载小文件.
如何彻底解决 ❓
-
解决瞬间无数个通知弹出的难题. 最多3个通知. 短时间内/瞬间内有多个的话 函数限制. .....
-
也许
函数防抖/节流
能带来曙光 ? 或许 能解决批量小文件下载的 瞬间并发难题? 很可能 还会彻底修复 无法下载的假死/性能问题 ? 参考 函数防抖和节流 ⤤ (代码在网页js里测试是有效的)
@dnknn 防抖和节流,很好的想法,最近我会试下,效果不错的话,会有一期更新
防抖和节流,很好的想法,最近我会试下,效果不错的话,会有一期更新
不着急慢慢来, 记着就好. 感觉应该能解决, 假如仍旧不行, 可参考这个仓库源码的逻辑 https://github.com/ehaagwlke/download-notifier
日常催更,cpu占用过高,单击扩展程序需要十几秒才有反应,并且文件图标显示不全
经过对比定位到问题,下载两个文件,由于下载 慢,直接把电脑卡死,一直在创建新的edge进程。。。。