TSM full restoration very very slow

huttivoli

ADSM.ORG Member
Joined
Mar 21, 2005
Messages
72
Reaction score
0
Points
0
I am trying to restore a full AIX system in test box and its too slow.

Around 1MB per minute. All the data resides in single tape and I am restoring one file system at a time.

below are the optioned defined in sys file
TCPWindowsize 640
LARGECOMmbuffers Yes
TCPBuffsize 512

LAN card is 100 MBPS with full duplex setting.

TSM server and client both are 5.5

I just need to restore 7 GB of data and I think it will take 2 days to complete.


Please guide
 
largecommbuffers is replaced with diskbuffsize, use diskbuffsize instead of largecommbuffers
 
Is the SWITCH and the HOST both HARD set to 100mbps, or have they autonegotiated to 100mbps.

Are you restoring lots of small files?
 
below is logs for one file restoration logs.

02/26/09 15:23:25 ANE4955I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Total number of objects restored: 308(SESSION:
129797)
02/26/09 15:23:25 ANE4959I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Total number of objects failed: 0(SESSION:
129797)
02/26/09 15:23:25 ANE4961I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Total number of bytes transferred: 58.27 MB(SESSION:
129797)
02/26/09 15:23:25 ANE4963I (Session: 129797, Node: SG01QNV02ICT5X5_DR) Data
transfer time: 3,820.01 sec(SESSION:
129797)
02/26/09 15:23:25 ANE4966I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Network data transfer rate: 15.62
KB/sec(SESSION: 129797)
02/26/09 15:23:25 ANE4967I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Aggregate data transfer rate: 5.58
KB/sec(SESSION: 129797)
02/26/09 15:23:25 ANE4964I (Session: 129797, Node: SG01QNV02ICT5X5_DR)
Elapsed processing time: 02:58:02(SESSION:
129797)
02/26/09 15:23:25 ANR0403I Session 129797 ended for node SG01QNV02ICT5X5_DR
(AIX). (SESSION: 129797)

--------------------------------

Currently I have started more restoration of file system, where its completed 42 MBin 38 minutes. I am restoring from LTO1 tape.

130,454 Tcp/Ip Run 0 S 8.3 M 719 Node AIX SG01QNV02ICT5X5_DR
130,455 Tcp/Ip SendW 11 S 33.0 M 981 Node AIX SG01QNV02ICT5X5_DR

tsm: SGDCW01>q restore f=d

Sess Restore Elapsed Node Name Filespace FSID File Spec
Number State Minutes Name
------ ----------- ------- ------------------------- ----------- ---------- ----------------------------------------
-1 Restartable 367 SG01QNV02ICT5X5_DR /usr/local 5 /**
130,45 Active 38 SG01QNV02ICT5X5_DR /usr/OV 11 /**
4

--------------------------------

Not sure why its so slow.
 
My Full restoration test failed. Restoration of 500 MB of data was taking 8 to 10 hours, It
 
You still didn't answer my question about your network speeds? Verify that they are hard-set and not left to auto-negotiate (especially if they are 100Mb). This is a big cause of this type of problem.

You could do a move nodedata to move the tape data to disk and restore from there too.
 
Sorry for late reply. I think my previous message was not printed fully.

Frankly saying, I have not used any of the options you mentioned. I am going to do this full restoration in coming 2 weeks time.

As per the network team, this server is going through multiple firewalls, which may have made this restoration slow.

(But my doubt is, while taking full backup of the same node in a disk with multiple sessions, it takes hardly 2 hours to complete (7 GB) with same firewall network. while restoration, 500 MB is taking 10 hours (all the data in single tape).

Also I was trying to restore full filesystem, may be because of this restoration was slow.

below is the command...

restore /pearl/tmp/data/ -subdir=yes -replace=all

Other then 2 options you mentioned (not left to auto-negotiate & largecommbuffers to diskbuffsize), what are the other settings need to be followed to restore faster like specific options in dsm.sys.
 
OK, then, let's get this made clear.
If you attempt to autonegotiate at 100Mbps, you will almost certainly get a duplex mismatch. Any duplex mismatch can destroy well over 99% of your throughput, under load. Where one might expect to run a steady 5+MB/S, a duplex mismatch can result in less than 20KB/S. The connection can appear to be good, with nice short latency, good times on large-packet pings, etc., but when you start trying to stream, outgoing packets stomp incoming packets, and vice versa. A stomped ACK for a correctly-received packet still causes every packet it acked to be retransmitted.

Check your server, like this(substitute your own physical adapter name(s)):
bash-3.00$ entstat -d ent1|grep Media.Speed
Media Speed Selected: Auto negotiation
Media Speed Running: 1000 Mbps Full Duplex
bash-3.00$
If your "Media Speed Selected" is "Auto negotiation" and your "Media Speed Running" is not "1000 Mbps Full Duplex", you know you have a problem before you even talk to your network guy. AIX can do 1000 only autonegotiate and all 1000bT connections are always full duplex, but there truly is no protocol for autonegotiating duplex, so usually your switch will go half and your card will go full.
If your speed running is NOT 1000, have your network guy do the equivalent for the switch port(s) you're using. Have him hard-code that port for the highest full-duplex you can both do, and then you do the same for your NIC.

I had a NIM server set up once and it turned out the switch was hosed, and running half-duplex. It made me look really bad when I tried to do a NIM recovery in a crisis. As always, it took nearly an act of Congress to get the network guy to eventually look at that port and see that it was running half though configured full. No other ports were available for us, but I got reasonably good performance by setting my server to half, to match.

The reason BBB has asked twice and now I'm asking, is that your issue closely resembles this one. If you don't look where the problem is, you probably won't find the answer.

Don't be like the guy I saw searching around in the bottom of his boat. I asked him what he was looking for, and he said he dropped his keys over the side. I asked him why he was searching inside the boat instead of on the bottom of the lake, and he said he couldn't swim.
 
Back
Top