主题:【求助】不灵了,请弟兄们帮忙 -- 萨苏
见鹿顶记注解
主要是俺的帖子下见的不多啊。。。
本帖一共被 1 帖 引用 (帖内工具实现)
送朵花试一下
这些天从Interface的duplex设定到Sky-X的Linktest进行的测试已经不下一百个了,问题依然如雾中看花。不过基本可以限定在网络的速度不平衡上,子矜等几位朋友的看法颇有道理。这个我最初是不大以为然的,因为网络方面双方的协议里有SLA,不应该有不平衡的问题,测试的时候带宽也的确达到要求,所以发现不平衡后一直在设备上找原因,现在看来。。。还难说,Vendor在作测试。问题很可能是Packet Loss导致的,确认中。
这场恶战的经验,可否成为萨老添IT那坑的材料呢?
“
...
我盼那盼那
盼东方出红日
...
”
------现代舞剧《白毛女》
老萨好可怜,俺实在是爱莫能助啊
如果PACKET SIZE没问题, 就是PACKET之间的时间差大了, 没有形成TRAIN。
问题可能出在那个加密设备上。 我建议你OFFLINE加密之后,再传送。
老萨的问题如果出在网络上的话,是一个标准的mpls vpn(level2 or level 3)的应用的问题,在用户端是难以解决的,只能碰运气了。这里个关键是用户对中间的TRAFFIC无法施加policy.这几年downturn,估计这种vpn的价格还没下来或根本就没有。。。。。。
有一个ROUTER在一个INTERFACE上overload,老萨一个星期不回家都没用!
从这个“症状”链接出处来看,问题很可能是在Office2(Server)端,而与网络无关。
“(Office2的)ACK MSG,里面的Window Size却在不断变化,从16K到0.3K”就会造成“从Office1向Office2传递的时候,(Throughput)为间断的波峰”。这里需要解释一下TCP Packet里的Window Size代表的是“receive window”,其目的是用于flow control。TCP协议中还有一种window是congestion window,用于congestion control。TCP sender在传送数据时,取两个window的最小值。receive window波动的原因一般和网络(congestion,packet loss)无关,而是由于receiver端的application process consume receive buffer的速度不够快。Packet loss或timeout会造成congestion window的波动,但当receive window只有0.3K的时候,throughput太低的原因基本上可以肯定是receiver端的问题。
我的建议是按以下顺序调查Office2上的:
1、application:这个可能性最大。application如果写的不好的话,无法处理大流量的数据,就会造成这种问题。可以试试在office2上用ftp从office1下载一个大文件,看看是不是还有throughput波动的情况。
2、operating system:这个可能性很小。win2000的tcp/ip协议栈的performance还是不错的,处理20M的流量应该没问题。可以试一试重装一个干净的系统,关掉其他所有不必要的service和application。
3、网卡:实在没办法了就换个网卡试试。
自己机器的网卡的link speed /duplex mode 设为100M Full,人家的设为auto,从人家那里拉东西,就老是纳闷:怎么大家都是用100M端口,局域网传输还这么慢吞吞的。后来把auto那台机改为100M Full就正常了。
老萨已经测试过无数次物理链路了。
1.假设如果物理线路没有问题,问题就在两台服务器上了。
建议:
两个办公室用两台普通工作站替代主机传送数据
前提是:两台工作站性能良好,经过了简单的网络传输测试
1.1如果测试结果表明传输速率正常,那么用替换的方式检测两台主机,找出哪一台主机有问题?
1.2传输速率还不正常
可能ISP的线路有问题,请设法检测路由器端口到ISP之间的线路啦,这个好像有点悬。