I must have under utilized my shift key, you are correct, for every 1Gb, you in
theory can get 100MB/sec.
I am not sure how slow the LTO4 can write, if it cannot go slow enough there
may be some shoe shining.
The external disks sound fine, the internals will depend on the config and
controllers,
On Thursday 30 April 2009, Huebner,Andy,FORT WORTH,IT wrote:
> 1 Gb Ethernet is about 100Mb/sec
Maybe nick picking, but for me: 100Mb = 100 Mbit, 100MB is 100 MByte.
> LTO4 is about 120Mb/sec + compression
Mhh, I was counting 80 MB/s up to 160 MB/s with compression ratio 2:1.
> A good SCSI or FC
1 Gb Ethernet is about 100Mb/sec
LTO4 is about 120Mb/sec + compression
A good SCSI or FC drive is good for about 100Mb/sec
Assuming you can stream 3 threads across the Ethernet, you will not be able to
keep the 3 LTO4 drives busy because of the network. The faster tape drives
were not intended
Hot Diggety! Mario Behring was rumored to have written:
>
> I´ve started a backup operation at a Linux client using CENT OS
> (similar to RHat). The operation took 1 hour and 59 minutes to finish,
> and backed up 5.45GB of data.I think this is kind of
> slow..considering that the
Looks to me based on the calculations if it goes over a little more than 2
hours acceptable. What's acceptable to me might not be acceptable to
others.
225 GB per hour, or 62.5 MB/s
LTO2 drives can writes 70 ~75 MB/s
It's difficult to PD without seeing the whole environment where the bottle
neck
Y. Lee
> William <[EMAIL PROTECTED]>
>
>
>
>
> William <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager"
>
> 06/23/2005 10:19 PM
> Please respond to
> William <[EMAIL PROTECTED]>
>
> To
> ADSM-L@VM.MARIST.EDU
> ADSM-L@VM.MA
Now I am not sure which parameter took effect.
Another thing I am not sure is the backup file size dropped to 50GB
from more than 100GB. I will keep monitoring it and post here.
Thanks for all your help!
On 6/23/05, William <[EMAIL PROTECTED]> wrote:
> Thanks Sung. I did not find any lanfree rel
Thanks Sung. I did not find any lanfree related issue. As I mentioned
in previous post. I changed 2 parameters:
1. resouceutilization from current 3 to 5
2. tcpwindowsize from current 128 to 63
Now the backup looks very good.
06/23/05 20:26:13 --- SCHEDULEREC STATUS BEGIN
06/23/05 20:26:13 To
Looking at the config, this appears to be lanfree backup client. If the
lanfree is broken, then normally TSM client will default to tcpip over lan.
If this is so, then I do see TSM storage agent version mismatch. From what
I understand, TSM server code and TSM storage agent should match.
Is it po
Hi Richard, TSM Server 5.3 is on AIX, the problem comes from TSM
Client 5.2.3 on HP-UX. But I did read your guide and tried to change 2
parameters:
1. resouceutilization from current 3 to 5
2. tcpwindowsize from current 128 to 63
Let's see how it goes.
Thanks.
On 6/23/05, Richard Sims <[EMAIL PR
ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Glanville
Sent: Thursday, June 23, 2005 1:47 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Backup Performance
TSM server 5.3.1.x has a bad bug. I am not sure if you are using that or 5.3.0
But if you are on 5.3.1, you could t
TSM server 5.3.1.x has a bad bug. I am not sure if you are using that or
5.3.0
But if you are on 5.3.1, you could try turning Collocation off for your
destination storage pools.
IBM APAR IC46349
This bug makes TSM 5.3.1 useless for sites backing up more than a few
servers.
Matt G.
William -
See IBM site Technote 1200328, particularly its comments on TCP
window size.
(Those on TSM 5.3 for HP-UX should see Technotes 1193325 and 1206956
regarding
TCPwindowsize and performance. Again, never take defaults.)
Richard Sims
Joshua,
The db and log are spread out among 8 Logical Subsystems.
Eliza
>
> Eliza,
>
> How many ranks (Logical Subsystems) is your DB and log spread out
> across? For highest performance, try spreading the load across as many
> spindles as possible.
>
> --
> Joshua S. Bassi
> IBM Certified - AI
Eliza,
How many ranks (Logical Subsystems) is your DB and log spread out
across? For highest performance, try spreading the load across as many
spindles as possible.
--
Joshua S. Bassi
IBM Certified - AIX 4/5L, SAN, Shark
Tivoli Certified Consultant - ADSM/TSM
eServer Systems Expert -pSeries HA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On dinsdag, september 3, 2002, at 06:16 , Roger Deschner wrote:
>
> I have had to use the brute force method - "dumb load balancing". That
> is, squeezing the database into the shape I want with DELETE DBVOL.
> Making this work takes careful advance
ESS is a complex piece of equipment and as any such one can be configured
in zillions of ways - some good, some bad and some of them perfect. With
proper configuration of the *whole* system you can get impressive results.
Check the settings of the AIX, FC HBAs, zoning and mainly the ESS LUNs. It
w
nt: Monday, September 02, 2002 9:17 AM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
On maandag, september 2, 2002, at 01:49 , Daniel Sparrman wrote:
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it.
> The two 21G da
In my experience, "smart load balancing" does not really exist. I
thought I had heard of it, so I went looking on my system to see if it
was doing anything to help. If the Database has plenty of room in it,
and you add a new extent in hope of spreading out the I/O load, that
extent will not be use
Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 12:19
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject:Re: backup performance with db and log on a SAN
>
>
> Thanks D
On maandag, september 2, 2002, at 01:49 , Daniel Sparrman wrote:
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it. The
> two 21G database disks, are each connected to it's own HBA?
>
> According to spec sheets, the 3590E FC could handle speed up to 100MB/s
> with
Roger,
Thanks for the detailed analysis. This is what I was planning to do: moved
the db back to attahced SCSI drives. Re-configuring one drawer in the Shark
to non-RAID as another person suggested is out of the question since TSM
is using only a small portion of the Shark. Please read the oth
obil: 070 - 399 27 51
>
>
>
>
> Remco Post <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 10:48
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
&g
. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Roger Deschner [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 01, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
What a FASCINATING data point!
I think t
Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Adolph Kahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 10:16 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
You are correct the at 3:1 compression you will not do better than
Sent: Monday, September 02, 2002 1:23 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
Daniel,
>
> Hi Eliza
>
> As I understand it, each "tape-HBA" has 3 3590E FC connnected to it.
The
> two 21G database disks, are each connected to it
On maandag, september 2, 2002, at 11:26 , Daniel Sparrman wrote:
> Hi
>
> The large disks you are talking about, are you meaning large as 36GB,
> 72GB
> an so on, or are you talking about LUN-sizes?
>
Disk size, 72 GB or so
> In a shark, you can have very large LUN:s, but they will consist
Remco Post <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
2002-09-02 10:48
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: backup performance with db and log on a
t; Exist i Stockholm AB
> Propellervägen 6B
> 183 62 HÄGERNÄS
> Växel: 08 - 754 98 00
> Mobil: 070 - 399 27 51
>
>
>
>
> Remco Post <[EMAIL PROTECTED]>
> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
> 2002-09-02 10:48
> Pl
On zaterdag, augustus 31, 2002, at 05:18 , Eliza Lau wrote:
> I recently moved the 36G TSM database and 10G log from attached SCSI
> disk
> drives to a SAN. Backing the db now takes twice as long as it used to
> (from 40 minutes to 90 minutes). The old
> attached disk drives are non-RAID and TSM
>
> Paul D. Seay, Jr.
> Technical Specialist
> Naptheon Inc.
> 757-688-8180
>
>
> -Original Message-
> From: Roger Deschner [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 01, 2002 2:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: backup performance with
Message-
From: Roger Deschner [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 01, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: backup performance with db and log on a SAN
What a FASCINATING data point!
I think the problem is simply that it is RAID5. The WDSF/ADSM/TSM/ITSM
Database is
What a FASCINATING data point!
I think the problem is simply that it is RAID5. The WDSF/ADSM/TSM/ITSM
Database is accessed rather randomly during both normal operations, and
during database backup. RAID5 is optimized for sequential I/O
operations. It's great for things like conventional email sys
You say you put it on SAN. What kind? I am guessing a Shark or FastT
device since it is an IBM SAN. If you only got 10% with Oracle and the
issues with TSM on the database I think you have your file systems on the
AIX machine setup incorrectly or another problem. It could be the tape
drive is
34 matches
Mail list logo
