Find Communities by: Category | Product

NetWorker有一个非常重要的参数,就是索引。这个参数对于备份和恢复都起到很大的作用。客户基本都知道索引的概念,但是如何有效地管理索引,如何更好的利用索引,却很多客户不太清楚具体的流程和操作。这里就和大家简单的介绍一下索引。

 

索引在生活和工作的很多方面都存在,每个人都应该对索引感到不陌生。我们的图书馆系统就有庞大的索引系统。您需要借阅一本图书,可以在电脑里面简单的根据书名,作者或者其它信息搜索,搜索结果告诉您图书的数量,具体的存书位置,是否可以借阅,如果借出什么时候可以归还等等。所有借阅者可以简单的通过网络来了解图书馆庞大的藏书系统。

 

NetWorker的索引客户基本上无法接触,客户端文件索引是NetWorker服务器的控制文件数据库之一,其它两个是resmm,这些数据库跟踪客户端备份的每个文件(路径名),从而允许用户浏览特定时间点的文件备份。NetWorker服务器在每个物理客户端上创建并且维护一个CFI.

 

客户端的文件索引存储由备份客户端生成的有关客户端的备份文件和目录的信息。对于备份的每个文件和目录,CFI将包含其路径名,文件属性(如权限和所有权)以及表明何时备份包含该文件的存储集的时间戳,NetWorker的客户端将跟踪信息发送至各自的CFI,后者驻留在NetWorker服务器上。每台物理客户端有一个CFI

 

经常会有用户突然发现自己的磁盘空间突然满了,源头就是索引文件夹过大。这个时候往往客户就会有疑问:为什么一个索引文件夹可以达到几十个G?这往往有两个可能性:

1. 客户设置的浏览策略过长。这个浏览策略决定了文件在CFI里面的保留时间。这个浏览策略的设置如下:

4271.png

2. 存储集的文件系统过于复杂。如果碎文件过多,也会影响索引的大小。

 

对于索引文件过大,这个问题怎么解决呢?对于这个问题,我们的解决方案有很多种。下面给大家简单介绍一下各种方法的实用性。

1. 可以通过命令行来修改浏览时间。这个命令的格式如下:

4272.png

2. 可以在NMC -> Media下面去删除索引:

4273.png

3. 我们还有一个解决方案。就是可以把索引文件夹整体迁移到其它硬盘下面。这个操作可以在客户端属性下面配置:

4274.png

 

通过及时地管理和维护索引信息,我们既可以有效地实现定时恢复,也不会造成备份环境的故障。这样才能高效的管理我们复杂的备份环境。

 

Mandy Xu

NetWorker技术支持工程师

Data Protection and Availability Solution

EMC客户服务

最近有不少同事开始学习Wireshark,他们遇到的第一个困难就是理解不了主界面上的提示信息,于是跑来问我。问的人多了,我也总结成一篇文章,希望对大家有所帮助。Wireshark的提示可是其最有价值之处,对于初学者来说,如果能理解这些提示所隐含的意义,学起来定能事半功倍。

1[Packet size limited during capture]

当你看到这个提示,说明被标记的那个包没有抓全。以图14号包为例,它全长有171字节,但只有前96个字节被抓到了,因此Wireshark给了此提示。

图1.png

1

 

这种情况一般是由抓包方式引起的。在有些操作系统中,tcpdump默认只抓每个帧的前96个字节,我们可以用“-s”参数来指定想要抓到的字节数,比如下面这条命令可以抓到1000字节。

[root@my_server /]# tcpdump -i eth0 -s 1000 -w /tmp/tcpdump.cap

 

 

2TCP Previous segment not captured

TCP传输过程中,同一台主机发出的数据段应该是连续的,即后一个包的Seq号等于前一个包的Seq+Len(三次握手和四次挥手是例外)。如果Wireshark发现后一个包的Seq号大于前一个包的Seq+Len,就知道中间缺失了一段数据。假如缺失的那段数据在整个网络包中都找不到(即排除了乱序),就会提示[TCP Previous segment not captured]。比如在图2这个例子中,6号包的Seq1449大于5号包的Seq+Len=1+0=1,说明中间有个携带1448字节的包没被抓到,它就是“Seq=1, Len=1448”。

图2.png

2

 

网络包没被抓到还分两种情况:一种是真的丢了;另一种是实际上没有丢,但被抓包工具漏掉了。在Wireshark中如何区分这两种情况呢?只要看对方回复的确认(Ack)就行了。如果该确认包含了没抓到的那个包,那就是抓包工具漏掉而已,否则就是真的丢了。

顺便分析一下图2这个网络包,它是HTTPS传输异常时在客户端抓的。因为“Len: 667”的小包(即6号包)可以送达,但“Len: 1448”的大包却丢了,说明路径上可能有个网络设备的MTU比较小,会丢弃大包。后来的解决方式证实了这个猜测,只要把整个网络路径的MTU保持一致,问题就消失了。


3[TCP ACKed unseen segment]

Wireshark发现被Ack的那个包没被抓到,就会提示 [TCP ACKed unseen segment]。这可能是最常见的Wireshark提示了,幸好它几乎是永远可以忽略的。以图3为例,32号包的Seq+Len=6889+1448=8337,说明服务器发出的下一个包应该是Seq=8337。而我们看到的却是35号包的Seq=11233,这意味着833711232这段数据没有被抓到。这段数据本应该出现在34号之前,所以Wireshark提示了[TCP ACKed unseen segment]

图3.png

3

 

不难想象,在一个网络包的开头会经常看到这个提示,因为只抓到了后面的Ack但没抓到前面的数据包。

4[TCP Out-of-Order]

TCP传输过程中(不包括三次握手和四次挥手),同一台主机发出的数据包应该是连续的,即后一个包的Seq号等于前一个包的Seq+Len。也可以说,后一个包的Seq会大于或等于前一个包的SeqWireshark发现后一个包的Seq号小于前一个包的Seq+Len,就会认为是乱序了,因此提示 [TCP Out-of-Order] 。如图4所示,3362号包的Seq=2685642小于3360号包的Seq=2712622,所以就是乱序。

图4.png

4

 

小跨度的乱序影响不大,比如原本顺序为12345号包被打乱成21345就没事。但跨度大的乱序却可能触发快速重传,比如打乱成23451时,就会触发足够多的Dup ACK,从而导致1号包的重传。

5[TCP Dup ACK]

当乱序或者丢包发生时,接收方会收到一些Seq号比期望值大的包。它每收到一个这种包就会Ack一次期望的Seq值,以此方式来提醒发送方,于是就产生了一些重复的AckWireshark会在这种重复的Ack上标记[TCP Dup ACK]

以图5为例,服务器收到的7号包为“Seq=29303, Len=1460”,所以它期望下一个包应该是Seq+Len=29303+1460=30763,没想到实际收到的却是8号包Seq=32223,说明Seq=30763那个包可能丢失了。因此服务器立即在9号包发了Ack=30763,表示“我要的是Seq=30763”。由于接下来服务器收到的10号、12号、14号也都是大于Seq=30763的,因此它每收到一个就回复一次Ack=30763,从图中可见Wireshark在这些回复上都标记了[TCP Dup ACK]

图5.png

5

 

6[TCP Fast Retransmission]

当发送方收到3个或以上[TCP Dup ACK],就意识到之前发的包可能丢了,于是快速重传它(这是RFC的规定)。以图6为例,客户端收到了4Ack=991851,于是在1177号包重传了Seq=991851

图6.png

6

 

7[TCP Retransmission]

如果一个包真的丢了,又没有后续包可以在接收方触发[Dup Ack],就不会快速重传。这种情况下发送方只好等到超时了再重传,此类重传包就会被Wireshark标上[TCP Retransmission]。以图7为例,客户端发了原始包(包号1053)之后,一直等不到相应的Ack,于是只能在100多毫秒之后重传了(包号1225)。

图7.png

7

 

超时重传是一个非常有技术含量的知识点,比如等待时间的长短就大有学问,本文就不细说了,毕竟需要懂这个的人很少。

8[TCP zerowindow]

TCP包中的“win=”代表接收窗口的大小,即表示这个包的发送方当前还有多少缓存区可以接收数据。当Wireshark在一个包中发现“win=0”时,就会给它打上“TCP zerowindow”的标志,表示缓存区已满,不能再接受数据了。比如图8就是服务器的缓存区已满,所以通知客户端不要再发数据了。我们甚至可以在32583263这几个包中看出它的窗口逐渐减少的过程,即从win=15872减小到win=1472

图8.png

8

 

9[TCP window Full]

Wireshark在一个包中打上[TCP window Full]标志时,就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。以图9为例,Britain一直声明它的接收窗口只有65535,意味着Middle East最多能给它发送65535字节的数据而无需确认,即“在途字节数”最多为65535字节。当Wireshark在包中计算出Middle East已经有65535字节未被确认时,就会发出此提示。至于Wireshark是怎么计算的,请参考本书的《计算“在途字节数”》一文。

图9.png

9

 

[TCP window Full]很容易跟[TCP zerowindow]混淆,实际上它们也有相似之处。前者表示这个包的发送方暂时没办法再发送数据了,后者表示这个包的发送方暂时没办法再接收数据了,也就是说两者都意味着传输暂停,都必须引起重视。

10[TCP segment of a reassembled PDU]

  • 当你收到这个提示,肯定已经在EditàPreferencesààTCP菜单里启用了Allow sub dissector to reassemble TCP streams。它表示Wireshark可以把属于同一个应用层PDU(比如SMBRead ResponseWrite Request之类)的TCP包虚拟地集中起来。如图10所示,这一个SMB Read Response3948号包共同完成,因此Wireshark在最后一个包中虚拟地把所有包集中起来。这样做有个好处,就是可以右键点击图10底部的方框,选择CopyàBytesàPrintable Text Only,从而复制整个应用层的PDU。做研发的同学可能比较需要这个功能。

图10.png
10

 

11Continuation to #

  • 你看到这个提示,说明已经在EditàPreferencesàProtocolsàTCP菜单里关闭了Allow sub dissector to reassemble TCP streams比如图10的那些包,一关闭就变成图11这样。

图11.png

11

 

仔细对比图10和图11,你会发现Read Response在图10中被算在了48号包头上,而在图11中被算到了39号包头上。这样会带来一个诡异的结果:图10的读响应时间为2.528毫秒(38号包和48号包的时间差),而图11的读响应时间为2.476毫秒(38号包和39号包的时间差)。究竟哪个算正确呢?这个问题很难回答,如果在乎的是实际的总性能,那就看前者;如果想忽略TCP/IP协议的损耗,单看服务器的响应速度,那就看后者。在某些特殊情况下,这两者相差非常大,所以必须搞清楚。

12.[Time-to-live exceeded (Fragment reassembly time exceeded)

ICMP的报错有好多种,大都不难理解,所以我们只举其中的一种为例。 [Fragment reassembly time exceeded]表示这个包的发送方之前收到了一些分片,但是由于某些原因迟迟无法组装起来。比如在图12中,由于上海发往北京的一些包被分片传输,且有一部分在路上丢失了,所以北京方无法组装起来,便只好用这个ICMP报错告知上海方。

图12.png

12

 

作者信息:

林沛满

林沛满是一位有近十年存储经验的技术专家,擅长文件存储的性能分析、归档和备份。同时也专注于网络协议分析,比如CIFS/NFS/HTTP/TCP/UDP等,是《Wireshark网络分析就这么简单》、《Wireshark网络分析的艺术》等书的作者。

 

注:本《大咖讲网络》系列文章取自《Wireshark网络分析的艺术》一书。

简介

作为技术支持,我们遇到过很多备份/恢复慢的问题。导致慢的因素各种各样,最常见的是网络带宽。如何判断网络带宽是否为瓶颈,今天和大家介绍一款利器iperf iperf是一款可以测量最大网络带宽的工具, 支持多种协议比如TCP/UDP和多参数搭配。常用功能:

    

TCP and SCTP 

  • 测试网络带宽
  • 报告MSS/MTU

      

UDP

  • 客户端创建指定带宽的UDP
  • 测量丢包
  • 测量延迟
  • 支持多播

          

下载

Avamar 服务器上本身自带了iperf工具(默认执行路径 /usr/local/avamar/bin),不需要安装,直接打命令iperf就可以使用

Linux客户端: 可以直接从Avamar 服务器上将iperf拷贝到客户端使用

Windows客户端:https://linhost.info/2010/02/iperf-on-windows/

 

使用方法

iperf的自带帮助文档很强大,运行命令iperf --help 可以将具体的参数列出


 

命令行选项


 

 

描述


 

 

客户端与服务器共用选项


 

 

-f, --format [bkmaBKMA]


 

 

格式化带宽数输出。支持的格式有:

  'b' = bits/sec 'B' = Bytes/sec

  'k' = Kbits/sec 'K' = KBytes/sec

  'm' = Mbits/sec 'M' = MBytes/sec

  'g' = Gbits/sec 'G' = GBytes/sec

  'a' = adaptive bits/sec 'A' = adaptive Bytes/sec

  自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字节,除非指定输出的格式,默认的参数是a。

  注意:在计算字节byte时,Kilo = 1024, Mega = 1024^2,Giga = 1024^3。通常,在网络中,Kilo = 1000, Mega = 1000^2, and Giga = 1000^3,所以,Iperf也按此来计算比特(位)。如果这些困扰了你,那么请使用-f b参数,然后亲自计算一下。


 

 

-i, --interval #


 

 

设置每次报告之间的时间间隔,单位为秒。如果设置为非零值,就会按照此时间间隔输出测试报告。默认值为零。


 

 

-l, --len #[KM]


 

 

设置读写缓冲区的长度。TCP方式默认为8KB,UDP方式默认为1470字节。


 

 

-m, --print_mss


 

 

输出TCP MSS值(通过TCP_MAXSEG支持)。MSS值一般比MTU值小40字节。通常情况


 

 

-p, --port #


 

 

设置端口,与服务器端的监听端口一致。默认是5001端口,与ttcp的一样。


 

 

-u, --udp


 

 

使用UDP方式而不是TCP方式。参看-b选项。


 

 

-w, --window #[KM]


 

 

设置套接字缓冲区为指定大小。对于TCP方式,此设置为TCP窗口大小。对于UDP方式,此设置为接受UDP数据包的缓冲区大小,限制可以接受数据包的最大值。


 

 

-B, --bind host


 

 

绑定到主机的多个地址中的一个。对于客户端来说,这个参数设置了出栈接口。对于服务器端来说,这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下,此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T参数。


 

 

-C, --compatibility


 

 

与低版本的Iperf使用时,可以使用兼容模式。不需要两端同时使用兼容模式,但是强烈推荐两端同时使用兼容模式。某些情况下,使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。


 

 

-M, --mss #[KM}


 

 

通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中,MSS值 为1460字节(MTU1500字节)。许多操作系统不支持此选项。


 

 

-N, --nodelay


 

 

设置TCP无延迟选项,禁用Nagle's运算法则。通常情况此选项对于交互程序,例如telnet,是禁用的。


 

 

-V (from v1.6 or higher)


 

 

绑定一个IPv6地址。

  服务端:$ iperf -s –V

  客户端:$ iperf -c <Server IPv6 Address> -V

  注意:在1.6.3或更高版本中,指定IPv6地址不需要使用-B参数绑定,在1.6之前的版本则需要。在大多数操作系统中,将响应IPv4客户端映射的IPv4地址。


 

 

服务器端专用选项


 

 

-s, --server


 

 

Iperf服务器模式


 

 

-D (v1.2或更高版本)


 

 

Unix平台下Iperf作为后台守护进程运行。在Win32平台下,Iperf将作为服务运行。


 

 

-R(v1.2或更高版本,仅用于Windows)


 

 

卸载Iperf服务(如果它在运行)。


 

 

-o(v1.2或更高版本,仅用于Windows)


 

 

重定向输出到指定文件


 

 

-c, --client host


 

 

如果Iperf运行在服务器模式,并且用-c参数指定一个主机,那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。


 

 

-P, --parallel #


 

 

服务器关闭之前保持的连接数。默认是0,这意味着永远接受连接。


 

 

客户端专用选项


 

 

-b, --bandwidth #[KM]


 

 

UDP模式使用的带宽,单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。


 

 

-c, --client host


 

 

运行Iperf的客户端模式,连接到指定的Iperf服务器端。


 

 

-d, --dualtest


 

 

运行双测试模式。这将使服务器端反向连接到客户端,使用-L 参数中指定的端口(或默认使用客户端连接到服务器端的端口)。这些在操作的同时就立即完成了。如果你想要一个交互的测试,请尝试-r参数。


 

 

-n, --num #[KM]


 

 

传送的缓冲器数量。通常情况,Iperf按照10秒钟发送数据。-n参数跨越此限制,按照指定次数发送指定长度的数据,而不论该操作耗费多少时间。参考-l与-t选项。


 

 

-r, --tradeoff


 

 

往复测试模式。当客户端到服务器端的测试结束时,服务器端通过-l选项指定的端口(或默认为客户端连接到服务器端的端口),反向连接至客户端。当客户端连接终止时,反向连接随即开始。如果需要同时进行双向测试,请尝试-d参数。


 

 

-t, --time #


 

 

设置传输的总时间。Iperf在指定的时间内,重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。


 

 

-L, --listenport #


 

 

指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。


 

 

-P, --parallel #


 

 

线程数。指定客户端与服务端之间使用的线程数。默认是1线程。需要客户端与服务器端同时使用此参数。


 

 

-S, --tos #


 

 

出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值,使用以"0x"开始的16进制数,或以"0"开始的8进制数或10进制数。

  例如,16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是:

  IPTOS_LOWDELAY minimize delay 0x10

  IPTOS_THROUGHPUT maximize throughput 0x08

  IPTOS_RELIABILITY maximize reliability 0x04

  IPTOS_LOWCOST minimize cost 0x02


 

 

-T, --ttl #


 

 

出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1,链接本地。


 

 

-F (from v1.2 or higher)


 

 

使用特定的数据流测量带宽,例如指定的文件。

  $ iperf -c <server address> -F <file-name>


 

 

-I (from v1.2 or higher)


 

 

-F一样,由标准输入输出文件输入数据。


 

 

杂项


 

 

-h, --help


 

 

显示命令行参考并退出 。


 

 

-v, --version


 

 

显示版本信息和编译信息并退出。


 

 

使用例子

我们以下面的环境为例展示如何测量Avamar客户端和Avamar服务器之间的最大带宽

Avamar 服务器:10.32.167.84

Avamar 客户端:10.32.198.93

  1. Avamar服务器上,运行iperf的服务器模式 (命令如下)

     iperf -s -i 1

     注释: '-s' 代表运行在服务器模式(接受数据); '-i 1' 代表以1秒为间隔做测试

   2.  Avamar客户端上运行客户端模式

     iperf -c 10.32.167.84 -i  1

   注释: '-c' 代表运行在客户端模式(发送数据); '-i 1' 代表以1秒为间隔做测试

Avamar服务器上看到的结果如下

1.png

Avamar客户端上看到的结果如下

2.png

从返回的结果,我们可以判断出这台客户端和Avamar服务器之间的最大平均带宽是51.6 Mbytes/sec; 换算成小时单位是 185760 MB/hour (181GB/hour)。也就是说这台服务器和Avamar客户端最大网络带宽是每小时181G。具体到Avamar,一般能用到最大带宽的50-70% 91--126GB/hour

    

附录

How to run iperf to compare performance between Avamar Server and client

https://support.emc.com/kb/305200

 

Jason Ma

Avamar技术支持工程师

Data Protection and Availability Solution

EMC客户服务

 

 

这也许称得上最经典的网络问题,很多大师从理论上分析过的,我能在现实中遇到也算三生有幸。

 

事情是这样的。有家公司来咨询一个性能问题,说是从AIX备份数据到Windows极其缓慢,只有1 MB/s,备份所用的协议是SFTP。我的第一反应就是抓个包,然后试试Wireshark的性能三板斧。

 

1.从Statistics->Summary菜单可见,平均速度是11 Mbit/s,的确只比1 MB/s高一些,见图1

图1.png

1

 

 

2.从Analyze->Expert Infos 菜单看,网络状况堪称完美。请看图2,连一个WarningsNotes都没有。这样的网络性能怎么会差?

图2.png

2

 

 

      3.选定一个从AIX发往Windows的包,然后点击Statistics->TCP StreamGraph ->TCP Sequence GraphStevens)菜单,从图3可见,这60秒中数据传输得很均匀,没有TCP Zero Window或者死机导致的暂停。

 

图3.png

 

3

 

 

试完三板斧,我们只能得到一个结论:备份的确进行得很慢,但是仅凭Wireshark自带的分析工具找不出根本原因,这也许意味着问题不在网络上,而是在接收方或者发送方上。幸好Wireshark不但能发现网络上的问题,也能反映出接收方和发送方的一些配置,只是需要一些技巧来发现。

 

因为数据是从AIX备份到Windows的,所以如果把SFTPSSH File Transfer Protocol)包过滤出来,理论上应该看到大多数时间花在了从AIXWindows的传输上。可是由图4发现,从AIXWindows的包虽然占多数,但没花多少时间。反而从WindowsAIX的两个包(533535)之间竟然隔了0.2秒。该现象在整个传输过程中出现得很频繁,说不定性能差的原因就在此处了。只要把根本原因找出来,就有希望解决问题。

图4.png

4

 

 

那么这0.2秒之间究竟发生了什么呢?我把过滤条件去掉后得到了图5所示的包。可见Windows发出533号包之后就停下来等,直到0.2秒之后AIXAck534号包)到达了才发出535号。Windows停下来的原因是什么呢?它在这两个包里总共才发了700多字节(96+656)的数据,肯定不会是因为TCP窗口受约束所致。

 

图5.png

 

5

 

 

如果你研究过TCP协议,可能已经想到了愚笨窗口综合症Silly window syndrome纳格Nagle算法。在某些情况下,应用层传递给TCP层的数据量很小,比如在SSH客户端以一般速度打字时,几乎是逐个字节传递到TCP层的。传输这么少的数据量却要耗费20字节IP+20字节TCP头,是非常浪费的,这种情况称为发送方的愚笨窗口综合症,也叫“小包问题”(small packet problem)。为了提高传输效率,纳格提出了一个算法,用程序员喜闻乐见的方式表达就是这样的:

 

if有新数据要发送

 

  if数据量超过MSS(即一个TCP包所能携带的最大数据量)

 

    立即发送

 

  else

 

    if前发出去的数据尚未确认

 

      把新数据缓存起来,凑够MSS或等确认到达再发送

 

    else

 

      立即发送

 

    end if

 

  end if

 

end if

 

 

 

5所示的状况恰好就是小包问题。Windows发了533号包之后,本应该立即发送535的,但是由于535携带的数据量小于MSS,是个小包,根据Nagle算法只好等到533被确认(即收到534)才能接着发。这一等就是0.2秒,所以性能受到了大幅度影响。那为什么AIX要等那么久才确认呢?因为它启用延迟确认了,具体可参考本书的《一篇关于VMware的文章》。

 

Nagle和延迟确认本身都没有问题,但一起用就会影响性能。解决方法很简单,要么在Windows上关闭Nagle算法,要么在AIX上关闭延迟确认。这位客户最终选择了前者,性能立即提升了20倍。

 

  • 如果你足够细心,也许已经意识到图3有问题—既然传输过程中会频繁地停顿0.2秒,为什么图3显示数据传输很均匀呢?这是因为抓包时间太长了,有60秒,所以0.2秒的停顿在图上看不出来。假如只截取其中的一秒钟来分析,再点击Statistics ->TCP StreamGraph->TCP Sequence GraphStevens)菜单,你就能看到图6的结果,0.2秒的停顿就很明显了。

 

图6.png

 

6

 

 

按理说,世界上到处都有启用了Nagle和延迟确认的设备在通信,为什么很少有人说起呢?我猜测大多数受害者并没有发现这个原因,以为是带宽不足所致,所以就一直忍着。我要不是用了Wireshark,也是发现不了的。根据我后来的搜索,只有斯坦福大学的博士Stuart系统地阐述过一个现实中的问题,文章在他的个人博客上http://www.stuartcheshire.org/papers/nagledelayedack/。我读完这篇文章的感觉就像遇到了知音,很想把这哥们约出来喝一杯:

 

“这么隐蔽的问题你是怎么发现的?太厉害了!”

 

“和满兄一样看包啦,分分钟的事!”

 

“论天下英雄,唯司徒君与满耳。”

 

……

 

本系列文章取自林沛满的《Wireshark网络分析的艺术》一书。

GENSTATS作业运行过程中,有时会出现如下错误,导致作业运行失败:

03.10.48 J0253806  -DLMDAILY DLM4VT4  STEP1      00    58    .00    .00    .00    625  0      0      0      0    0    35

03.10.48 J0253806  -DLMDAILY DLM4VT4  STEP2      00    50    .00    .00    .00    337  0      0      0      0    0    36

03.19.48 J0253806  -DLMDAILY DLM4VT4  STEP3      00    35    .00    .00  9.00    163  0      0      0      0    0    37

03.19.48 J0253806  EDG8197I VOLUME BFL999 IS NOT DFSMSrmm MANAGED

03.19.48 J0253806 *IEC501A M 06FC,BFL999,NL,,DLMDAILY,STEP4.DLM4VT4,BFL999.FLAT

03.19.48 J0253806  IEC502E K 06FC,BFL999,NL,DLMDAILY,STEP4,BFL999.FLAT

03.19.58 J0253806  -DLMDAILY DLM4VT4  STEP4      08    65    .00    .00    .17    892  0      0      0      0    0    38

03.19.59 J0253806  -DLMDAILY DLM4VT4  GO      FLUSH      0    .00    .00    .00      0  0      0      0      0    0    39

03.19.59 J0253806  +DLM8888E An ERROR Has Occurred in last step SA390

03.19.59 J0253806  -DLMDAILY DLM4VT4  DLMWTO      12    44    .00    .00    .00    512  0      0      0      0    0    40

03.19.59 J0253806  IEF404I DLMDAILY - ENDED - TIME=03.19.59    

        这是因为主机作业运行GENSTATS时,主机发命令给DLm的VTE要求VTE收集性能数据,VTE会运行find –n BFL***.FLAT命令查找文件,这个命令会在整个目录里搜寻文件,如果找到文件,就将生成的新文件替换老文件;如果没有找到,就将新文件放到control device对应的目录下。    

        问题出在find命令上,这个find命令运行时间较长,在运行过程中有时会中断,在VTE上无法生成文件,因而造成主机的作业失败。 解决方案是在作业里直接加上path name, 例如://DLM4VT1  EXEC GENSTATR,CMD=999,UNIT=/06CC,UNIT2=06CD, PATH='/tapelibDRZJ' , 这样就省去了find命令,同时也节省了运行时间。    

        修改后的运行结果是这样:

03.02.25 J0064006  -DLMDAILY DLM4VT4  STEP1      00    38    .00    .00    .00    361  0      0      0      0    0    35

03.02.25 J0064006  -DLMDAILY DLM4VT4  STEP2      00    55    .00    .00    .00    440  0      0      0      0    0    36

03.02.26 J0064006  -DLMDAILY DLM4VT4  STEP3      00    36    .00    .00    .00    191  0      0      0      0    0    37

03.02.26 J0064006  EDG8197I VOLUME BFL999 IS NOT DFSMSrmm MANAGED

03.02.26 J0064006 *IEC501A M 06FC,BFL999,NL,,DLMDAILY,STEP4.DLM4VT4,BFL999.FLAT

03.02.27 J0064006  IEC502E K 06FC,BFL999,NL,DLMDAILY,STEP4,BFL999.FLAT

03.02.27 J0064006  -DLMDAILY DLM4VT4  STEP4      00  1384    .00    .00    .01  3557  0      0      0      0    0    38

03.02.27 J0064006  GEN100I INPUT RECORDS  : 0000001204

03.02.27 J0064006          PASSED FILTERING: 0000001204

03.02.27 J0064006          MOUNT RECORDS  : 0000000602

03.02.27 J0064006          UNLOAD RECORDS  : 0000000602

03.02.27 J0064006          MOVED VOLUMES  : 0000000000

03.02.27 J0064006  -DLMDAILY DLM4VT4  GO          00    194    .00    .00    .00    916  0      0      0      0    0    39

03.02.27 J0064006  -DLMDAILY DLM4VT4  DLMWTO  FLUSH      0    .00    .00    .00      0  0      0      0      0    0    40

03.02.27 J0064006  IEF404I DLMDAILY - ENDED - TIME=03.02.27

修改后同时看到运行时间从9分钟缩短到只剩2秒钟。

Filter Blog

By date:
By tag: