Linux下哪个BT软件像BitComet一样有缓冲区?
要不大家的硬盘肯定扛不了多久。 :wink:应该动员大家一起寻找。 8) ctorrent,可以设置缓冲大小 第一次用win下面的azureus发现win版本的可以设置磁盘缓冲 但是linux版的(gtk2)的没有
难道win真的比较...? 第一次用win下面的azureus发现win版本的可以设置磁盘缓冲 但是linux版的(gtk2)的没有
难道win真的比较...?
GNU/Linux 的设计中有一点建议, 就是尽量的使用内存, 所以, 只要你的内存够多, 你的整个 ISO 文件几乎一直都呆在缓存里了.磁盘缓冲已经由 linux 系统级上做了, 你就不必担心了. 是啊 不过看起来做针对性的缓冲还是有一定效果的
看了一下btcomit的写命中率 一般徘徊在93%左右
看linux下的write 和merged write次数之比 大概是4:7的样子吧
我不知道这个merged wirte怎么算的 不过命中率最高就是7/11=63%
(512M ram /about 370M cached)
如果是每天24小时开着下bt的机器 这可是很可观的写入次数那 azureus最新的2.2.0.0已经加入磁盘缓冲的功能了。。 我相信在磁盘缓冲上,linux绝对比win做得好。在linux不用设置缓冲,因为操作系统已经帮你做了。在win上,你就不能只靠操作系统了。
当然软件自已做缓冲,对这个软件而言,缓冲命中率提高了,但是整个系统的效率就下降了,结果是BT不读写硬盘了,其它软件却开始狂读。
简单的试验,512M内存,在console下做一个500MB以内的种子。半天你的硬盘灯都不动。这时,你运行一下ls,就会发现硬盘灯乱闪。
所有的BT中,下载写缓冲都不存在问题。你看一下BT下载的信息,一般同时下载的就那么十几个块。每个块256KB/512KB,就那么几M的量。而且有可能是每个块下载完了一次性写入。但是上传却是随机块(其它peer请求的,甚至有的peer只请求了一个块里面的1/16或1/32,又转到其它块)。缓存命中率会比较低。所以比写命中率没有意义。
当然如果在BT客户端做些改进,也可以大大提高读命中率(比如在所有上传请求中,优先满足数据在缓冲区的上传)。linux下很多BT客户端是open-source的,大家有兴趣拿一个来改改。 我这里73%左右 是啊 不过看起来做针对性的缓冲还是有一定效果的
看了一下btcomit的写命中率 一般徘徊在93%左右
看linux下的write 和merged write次数之比 大概是4:7的样子吧
我不知道这个merged wirte怎么算的 不过命中率最高就是7/11=63%
(512M ram /about 370M cached)
如果是每天24小时开着下bt的机器 这可是很可观的写入次数那
怎么来看的??用什么命令?? 哇考 这也考古啊 (nnd 我问的那个剧简单的包问题就没人考出来?)
回楼上 vmstat -d可看
发现azureus比较老实 是按照大小算的 所以算出来效果不高
bitcomet比较赖是按次数算的 所以动不动就是98%的效率 昨天想用BT下载了,印象中有这么一帖,拉出来问问也不错!! :mrgreen::mrgreen::mrgreen:
页:
[1]