As a Netbackup admin, solving other problems may not be a stranger to you. Most seen is very bad backup performance. This article describe the test tool i use in my day to day work.
A utility created by Symantec (previous Veritas). It's splendid tool for finding bad disk performance, read or write. Works best on VXFS file system (obvious). Vxbench has diffrent workload built in (seq read/write - random read/write) and you can specify block size as well. I always check new disk storage unit with vxbench before putting them i production. Vxbench is available for Solaris, AI, HP-UX and Linux - The package is called VRTSspt and can be downloaded from Symantec site.
vxbench -w write -i iosize=128,iocount=262144 /diskstu4/dsu/testfile1
total: 111.531 sec 300852.32 KB/s cpu: 48.65 sys 0.04 user
A freeware java based network performance utility. Can be run on any OS with a Java VM. Can be obtained from Netcordia. . In order for reliable figures the amount of data send/received must be tweaked.
On the reciver side: java ttcp -r -l 65536 -n 16384
And on the reciver side : java ttcp -l 65536 -n 16384
Output look like this:
Transmit: buflen= 65536 nbuf= 16384 port= 5001
Transmit connection: Socket[addr=lena/10.1.22.134,port=5001,localport=59154].
Transmit: 1073741824 bytes in 10913 milli-seconds = 98391.08 KB/sec (787128.6 Kbps).
Whenever a firewall closes inn on you, tcpdump is you're find. You don't need to understand all the stuff, it's reasonable easy to see connections in and out.
Here is a list of my most often used tcpdump commands. I always use the following arguments
-i To specify what interface to listen to eg. eth6
-f Causes tcpdump to print internet addresses in numerical notation
-n Prevent service port to get translated into names (prints 13720 insted of bpcd).
Listen for traffic for a entire network
# tcpdump -n -f -i eth6 net 10.10.10.0/24
Listen for traffic for just one host
# tcpdump -n -f -i eth6 host 10.1.1.1
Or just one service port.
# tcpdump -n -f -i eth2 port ssh
# You can also trace traffic for two host on a IP only layer.
tcpdump -n -f -i eth1 ip host 10.224.13.1 or 10.224.13.2
Listen for traffic but don't clutter the picture with your'e own SSH traffic
# tcpdump -n -f -i eth5 ip and not port 22
Using Netbackup bpbkar as test tool
You can run bpbkar (the process responsible for reading from disk) by hand to see how performance is when network/tape drive layer is cut off. When issuing bpbkar by hand data is read from disk and thrown in the bit bucket. This will enable the admin to find out weather the problem is on the client side or server side.
d:\VERITAS\NetBackup\bin\bpbkar32.exe -nocont D:\ 1> nul 2> nul
/usr/openv/netbackup/bin/bpbkar -nocont -nofileinfo -nokeepalives /var > /dev/null 2> /tmp/file.out
Make sure you have created the bpbkar debug directory in C:\Program Files\VERITAS\NetBackup\logs before starting. The command is return immediately, but the process will be visible in task manager, and the debug log will grow in size as well.
if bpbkar run by hand takes the same amount of time as a real backup, you know the problem is on the client and know where to chase the next bottleneck.