写命中率导致崩溃的解决过程.

我的机器是xp,这机器虽然老,但是功能就是下载电影和看电影.我配的是2个1T的硬盘.,无论是CPU或者内存.基本是够用的.原来一直是用比较老的bitcomet版本的,去年升级到1.5几.然后因为有一些种子一直下不完,大约在4月头,我升级到1.6几.不少种子下完了.然后就出现问题了.软件变得容易崩溃.崩溃以前也不是问题.自动重启继续下就是了.但是现在崩溃后,我发现一些文件就会去掉.bc!,“看起来好像是一个正常的文件”.
但是打开却是有问题的.进度上看,仍然是未完成状态.那我就想,如果能维持不崩溃状态.最少可以下完.但是从1.6几一直升级,升级到1.67,这个问题似乎一直都在.似乎和写命中率也有关系.当时我大概有300个种子没下完,我的磁盘写次数,过了几分钟,就会飙高.从1次多两次每秒会飚升到四五十,甚至上百次每秒,然后写命中率就会飞快的下降.到了20%左右,然后软件就崩溃了.我的内存是3G,做了6G的虚拟内存.
和论坛的各位请教后,缓存无论调整大或者小,都没办法解决问题.
我也尝试把光猫的虚拟主机协议只配置为TCP.结果都差不多,实际磁盘写次数在到100次左右开始飚升.累计下载数据并没有同步上升.到频率100次每秒,大约1万次左右,写命中率就低过20%.然后就崩溃了.
在本周一,我突然想到.不然试试一部分一部分下载.所以先开了一部分比较新的种子.结果发现很顺畅.平均每秒频率1点多,1M每秒的下载速度.然后我就开始边下载边重新检查完整性.检查完.一部分一部分开始下载.然后发现有几个种子开了.实际磁盘写次数就开始暴涨.我本来想尝试一个一个关了.看是不是能找到试哪个出问题了.结果还没等到我找到,就崩溃了.然后我就把那几个种子全删了.继续往前检查完整性然后开始下载.虽然最后我也不知道究竟发生了什么事.不过我想大概就和排除电脑部件故障用排除法一个道理.
我发现,没问题的种子.开了,会一直没问题,无论是5分钟或者半小时甚至更长时间.实际磁盘写次数,会和下载数据同步增长.但是一旦增加了有问题的种子.实际磁盘写次数就会在几分钟内迅速增加.而且这种增加即使在把有问题的种子删掉后,还是会继续.不过把全部都停止下载.然后重新开起来.就又一切正常.
到昨天为止,我已经清掉了几乎所有老的种子,因此相对稳定,基本上要2小时左右.才会碰到飚高,而昨天晚上把剩下的39个旧的种子(这部分我原来以为没问题,因为在比如半小时内平稳,我在当时开其他种子就暴涨),删到剩下12个,从今天早上9点,到晚上7点,大概下载了25G,一万来次磁盘写次数后数据又开始上涨.当然.相比之前,也就涨到每秒十来次而已.这样我就有足够的时间关闭程序,以避免意外崩溃.而7点钟这次重开程序,下载50来个种子,到现在3个多小时.实际磁盘写次数16000多次.下载已经达到25G.3G的的内存用的不过1G,进程堆128.5M 磁盘缓存428M,UDP缓冲区437M.虚拟内存似乎没怎么占用.

而我那些删掉的种子,我舍不得就这么直接丢掉.所以我尝试用我另外一台工作的机器来下载,当然,平时我也不用工作的机器下来.这机器是WIN7,8G内存,2个500G的硬盘.去年11月我也用过工作用的机器下载过一批文件.大概同时运行三百来个也很顺畅.这次被我删掉的种子大概也是300多个.开始下载却感觉很吃力.硬盘灯经常狂闪,其他软件都反应迟缓.这个时候,用的是bitcomet 1.64.我观察了一下,内存占用基本上超过90%.大概折腾了2天.我想的解决方案是把软件升级到1.67,另一方面是虚拟内存由原来只有C盘的最多8个G.改成2个硬盘各11个G(这数字是win7 推荐的).就解决了硬盘灯狂闪,其他软件反应迟缓的问题.对日常工作就不会有影响.比如现在win7的内存使用是进程堆1.2G.磁盘缓存60G.UDP传输缓冲区10.4G.tracker日志缓冲区305 MB.物理内存的使用85%.不过现在还有另外一个问题,就是停止下载非常吃力.我去年11月用的win7,和xp停止下载,大概都是几秒的时间.但是现在的win7 bitcomet 1.67,停止下载大概是一分钟最多关3个的程度.比如我一次性停止100个种子.需要半个小时左右的时间.才能完成.当然,对我来说,问题并不是很大,比如我预计11点关机,那9点开始逐步停止下载就可以了.
现在看来,我的2台机器里面,win7是更稳定的.

到最后,我还想请教一个问题.就是我的xp,如果再次出现实际磁盘写次数剧烈飚高,这次的处理方法下次未必就能用了.而现在还得经常性的看着,以避免一不小心碰到崩溃,(导致部分文件的bc!去掉,但是文件仍然是未下载完的,都不能用.)没办法放心挂机.

所以如果把我的xp换成win 7系统,xp的cpu和内存都大大的不如我的win7.停止下载,比如同样300个种子会不会也要2个小时甚至更长?
最后再次谢谢各位的指导.

win7有俄罗斯人精简版的,可以做到内存占用1G左右。所以对于系统的关系并不大。
xp与win7的区别,我并不清楚。不过可以据我的经验举个例子;win10以前的系统默认不支持对硬盘trim操作,win10默认支持对硬盘trim.所以有些软件的win10版在win7上就无法运行,反之亦然。还有之前我用过赛扬G系列的一颗u(至少有10年了)。由于这颗u不支持SSE2指令集,因此类似chrome浏览器在某版本之后就无法运行,因为chrome在这之后似乎需要SSE2指令集。因此,软件并不是越新越好,要结合你的硬件分析。
最后,我给出你的建议:选择一个精简稳定版本的win7,安装一个相对稳定版本的bitcomet(不需要最新,稳定工作就可以)。关闭系统更新,谨慎更新软件
如果还不行,建议调低最大连接数。其实bitcomet算是占用资源比较大的。个人的建议是使用非官方精简版的,去除种子市场、评论等功能。

放假日, 睡飽飽起床, 看到如此長文的文章… 喝著咖啡, 吃著早餐好好理解一下… (平常日直接跳過不看… XD)

老舊機 XP 32bit 內存 3G 虚拟内存 6G 開任務300個 彗星版本1.5 資源沒下完, 升級 1.6 會崩
工作機 Win7 內存 8G 虚拟内存 C: 11G + D: 11 G 彗星版本1.5 300個任務秒停, 1.6 要停2个小时甚至更长

自己是沒開這多任務… 抓完就停掉, 頂多 1-10 個上下… 無法給建議… 不過蠻好奇… 不是有長效做種… 為何要開如此多任務?

彗星開 14 hrs, 就 2 百多 G 分享出去…

他可能拿来挂pt的,国内pt的速度大概就49-50kb/s,不多开会浪费水管啦

原來如此… 學習了…XD

感谢这么详细的反馈。如果崩溃的时候能显示错误报告窗口的话,麻烦点开详细描述,随便添加几句话,便于我查找到你的错误报告进行分析。
最近半年的这些版本,跟你描述问题有关的改动,大概有以下这些:
1、任务启动、停止由同步方式改为工作线程异步完成,避免主线程界面卡顿;
2、BT上传由直接主线程直接读盘变为工作线程读取到缓存里再上传;
3、BT下载写入缓存遇到物理内存或虚拟内存余量较少时,变为直接写盘,避免内存不足崩溃;
如果你的XP是32位版,目前BitComet 32位版的内存管理没有专门进行过测试,有可能出现各种奇怪的问题。如果方便的话,可以试试看64位版是否容易遇到上述问题。

好的,明白,下次碰到崩溃我会加上remark,并在这个帖子写同样的字句.

1個讚

这十几天来,我没有碰到崩溃的情况.可能是因为大批种子删掉之后.现在在下载的不超过100个种子.今天我又加了一批种子.大概100个.结果发现在半小时后,实际磁盘写次数又急剧上升.写命中率下降很快.但是这次我的处理方法是把机器转成win7(在上次发生状况后,我重新划了一个WIN 7的分区,可以用WIN 7启动),WIN 7启动后,我先是用原来的1.66. 32位版本的继续下载,结果还是出现同样的问题.之后我把我原来WIN 7的1.67 64位版本的BITCOMET.EXE单个文件COPY过来.重新打开.我发现初期实际磁盘写次数急剧上升.但是同时,很明显的下载数据有同步在动,可以达到10m/秒.写命中率没有下降.我再仔细看我今天的那些种子.我发现有部分是划分为128K一块的.那很明显,当10M有5M是128k一块的.一秒就是得写40次.所以我现在猜测原来出问题是因为在32位的状态下,大批小分块的数据写不成功.但是在64位的状态下,就写进去了.到现在,运行了7个多小时,下载36G,实际磁盘写次数4万次.写命中率98.1%.看来后面我会改成用WIN 7.问题应该最终能解决.

1個讚

这两天,我的原来的WIN7又碰到了问题,就是我发现实际磁盘写次数开始飙涨,而写命中率下降.WIN7的配置是8G内存,bitcomet 1.7.由于我一直害怕崩溃.所以先是删了一批种子.发现仍然是过一会会飙涨.后面我就把老机器用的1.67替换1.7.同时观察内存的使用情况.结果发现同样有飙涨的情况,发生再可用物理内存降低到384M,也就是我设定的最少保证的时候.飙涨到物理内存回升到这个数字以上.实际磁盘写次数就会下降到正常水平.另一方面,我也观察到虚拟内存好像吃不动.我昨天之前,虚拟内存是按照系统推荐的数字设置.但是因为昨天的情况,我尝试把虚拟内存加大50%.结果之前19G左右的虚拟内存.可以吃到剩下2G.今天则显示我有23.7G的虚拟内存.但是在13.7G左右.虚拟内存就一直维持这个数字.明天我再观察看看是不是有什么新情况.



今天状况再次更新:随附3个图片,第一个是任务管理器里面看到的内存使用情况.提交的内存,大约有5G用的是物理内存.
第二个是物理内存低于最少保证.实际磁盘写次数狂飙的场面.
第三个是过了一会,物理内存恢复到最低保证,实际磁盘写次数恢复正常的场面.
首先说明一下,我现在大约在下载340个种子.500G以上.机器是8G的物理内存.
今天早上,我开机的时候,最低保证内存是设定在384M.开机开完所有下载,就出门了.大概一个小时,回来发现实际磁盘写次数已经超过10万.写命中率只剩下57%左右.下载了大约10G的东西.虚拟内存仍然只吃到10G左右.
赶紧把所有任务关掉,大概一个小时才全部关掉.把2个硬盘的虚拟内存都设定为16G.
重新开机,然后观察到,最低保证内存一突破,实际磁盘写次数就飚.而384M的设定,经常被突破.我估计这就是我出去一小时,实际磁盘写次数超过10万,写命中率57%的原因.
我把384改成256,状况有好转.我的想法是软件在最低保证内存突破后,首先是把缓存中的数据写到虚拟内存.但是在虚拟内存已经吃满(或者暂时吃不进去)的情况下.就直接写硬盘了.但是缓存里面的东西.大部分都不是下载的文件必要的数据.就出现写硬盘写不进去,从而导致写命中率降低.而我出去这1个小时,因为384的门槛过高.导致轻易就突破.然后不断的写硬盘.
我刚切图的时候,软件重新启动刚好8小时,虚拟内存是吃了15G.累计是下载了34.4G,显示实际磁盘写次数接近24万次.以真正下载的数据大概0.5M大概写1次的话.34.4G的累计下载量,大约有效的磁盘写次数,应该在7万次左右.24万次.其中有大约17万次是无效的.
当然,我现在也明白,如果不是一次性下那么多东西,把任务砍掉一半的话,恐怕这个问题就不会有.不过我既然碰到了,就还是报告一下.

你这个是很老的旧版本了,升级到1.71看看呢?还有问题的话,把统计分类的完整信息贴一下

升级到1.71,内存的问题应该解决了,似乎是UDP缓存清除的结果.当然,退出后内存要全部清完,退出进程要花的时间比原来多,不过可以承受.
另外,很奇怪的是,升级完,1.71版本加新种子后,种子存档数量不会增加.但是1.67版本就会.