雪崩效应
我们的分发系统要从一个源节点向N个末端节点分发F个文件,N在10到200之间,F
则在1个/天到10000个/天之间,文件大小在32byte到2G 之间。这些节点可能散布
在新疆北京深圳,电信网通教育网。末端节点获知源节点有文件要分发的时候,用
udp协议向源节点发送request,而源节点回复 reply包。为了提高效率,我们加了
一个中间节点,这个中间节点把要分发的文件分片cache在自己的内存里,这样只
要一个末端请求了123.flv文件的0x101分片,其余的末端再请求123.flv的0x101分
片的时候,中间节点就可以直接返回给它了。
则在1个/天到10000个/天之间,文件大小在32byte到2G 之间。这些节点可能散布
在新疆北京深圳,电信网通教育网。末端节点获知源节点有文件要分发的时候,用
udp协议向源节点发送request,而源节点回复 reply包。为了提高效率,我们加了
一个中间节点,这个中间节点把要分发的文件分片cache在自己的内存里,这样只
要一个末端请求了123.flv文件的0x101分片,其余的末端再请求123.flv的0x101分
片的时候,中间节点就可以直接返回给它了。
问题来了,我们最近发现发送的文件如果总大小很大,比如5个小时内向60个ping
值差异很大的节点发送500个80M的文件,则cache会失效,中间节点疯狂的向源节
点转发末端节点的request包,源节点被迫不断的做磁盘随机读取,由于源节点上
磁盘随机读取非常耗时间,于是源节点无法及时回应请求包,而这又导致末端节点
继续发送请求,形成雪崩效应。源节点上listen端口的Recv-Q长久维持一个最高
值。于是整个系统的效率急剧下降。以前1G 的文件五分钟可以分发完毕,但是现
在我们上周试图同时分发50G文件,发了一个周末只有几百M的文件被发出去了。
这里根本的问题就是我们的系统没有过载保护。
0 Comments:
Post a Comment
<< Home