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's own HBA? Yes, you are correct. > > According to spec sheets, the 3590E FC could handle speed up to 100MB/s > with 3:1 compression. This means that with 3 drives, you could have up to > 300MB/s. However, the HBA will only theoretically handle 125MB/s, or > 250MB/s with 2Gb FC. We have 1Gbit FC adapters. Are you sure that the 3590E FC drives can stream at 100MB/s? We were told that the tape drives are the bottleneck and not the adapters. > > Thie means that the tape drives will not stream the data, cause the data > flow will be queued(Some data to drive1, some data to drive2, some data to > drive3 and so on). There should be some wait % on the drives. > > What kind of a machine are you running? The smallest machine I know of > that is sold today and could handle this amount of adapters, is the > P-Series 660, which has 3 or 6 PCI busses. Normally, you don't want > multiple FC HBA and Gb Ethernet adapters mixed in the same PCI bus, as > theese are considered high-performance adapters that can utilize the whole > bandwidth of the bus. We have a P-Series 660 7026-6H1 with 12 PCI slots. The other adapters being used besides the 4 HBAs are a SCSIRaid adapter and a graphics monitor adapter. There are also 4 SCSI adapters left over from before the tape drives were converted to FC. They should be taken out. > > How many other adapters are installed in the machine? Gigabit Ethernet, > 10/100 ethernet and so on. The 10/100 ethernet has its own adapter, not in the PCI slots. > > Best Regards > > Daniel Sparrman > ----------------------------------- > Daniel Sparrman > Exist i Stockholm AB > Propellerv�gen 6B > 183 62 H�GERN�S > V�xel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > > Eliza Lau <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist 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 Daniel, > > The host has 4 HBAs. Two attached to each of the two switches. One HBA is > > zoned for tape traffic and the other for disk traffic. Only the db and > log > are on the Shark F20. The disk stgpools are on attached SCSI disk drives. > The disks are 36G. There are 8 LSSes. Each LSS is striped across 8 > drives > and sliced into 21G partitions. The db is on two of these 21G slices. > Tpae library is a 3494 with 6 3590E FC drives. All drives are connected > to the two switches, three each. > > Come to think of it, the Shark only has 2 HBAs. I have to verify this, > since > I am typing this from home. But it only has to read from the Shark and > write > to tape through another port in the switch. > > Eliza > > > 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? > > > > In a shark, you can have very large LUN:s, but they will consist of a > > large number of smaller SSA-based hard drives. This means that you will > > not have a performance impact on the disks. > > > > Normally performance issues on TSM / SAN has to do with having disks and > > > tapes on the same HBA. DB transactions is very randomly written, so if > you > > for example are doing migration, TSM will write to both disks and > tape(DB > > transactions to disk, migration from disk, migration to tape). This will > > > have a huge impact, as the HBA is arbitrated(which means only one write > > can be done at a time). Also, doing backups and migration directly to > > tape, assumes the ablility to write continous, sequential data. If you > > have the DB on the same card, your clients, or the TSM server, won't be > > able to stream data to the tapes, leading to poor performance. > > > > Eliza, I'd suggest you use somekind of monitoring tool, like the > Storwatch > > specialist, to see throughput from/to disks and tape. I'm sure that if > you > > separate the disks from the tape, you will see a performance upgrade. > > > > How many HBA:s do you have in your Shark? > > > > Also, check to see that the logs, diskpook and database is not on the > same > > volumes. This will also generate bad performance. > > > > The best practice is to have db & log on one HBA, diskpool on one HBA, > and > > tape drives on one or more HBA:s(depending on amount of tapes drives). > > This is however recommended for large environments, with > 200 mid-size > > clients. > > > > Best Regards > > > > Daniel Sparrman > > ----------------------------------- > > Daniel Sparrman > > 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 > > Please respond to "ADSM: Dist Stor Manager" > > > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: Re: backup performance with db and log on a SAN > > > > > > 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 mirrored. The SAN drives > are > > > RAID-5 and TSM mirrored. I know I have to pay a penalty for writing > to > > > RAID-5. But considering the massive cache of the SAN it should not be > > > too bad. In fact, performance of client backups hasn't suffered. > > > > > > However, the day after the move, I noticed that backup db ran for > twice > > > as long. It just doesn't make sense it will take a 100% performance > hit > > > from reading from RAID-5 disks. Our performance guys looked at the > sar > > > data and didn't find any bottlenecks, no excessive iowait, paging, > etc. > > > The solution is to move the db and log > > > back to where they were. But now management says: "We purchased this > > > very expensive 2T IBM SAN and you are saying that you can't use it." > > > Meanwhile, our Oracle people happily report that they are seeing > > > the performance of their applications enjoy a 10% increase. > > > > > > Has anyone put their db and log on a SAN and what is your experience? > > > > Yes we have. SAN is very bad for database performance. We used it as a > > temp storage space while we were reorganizing the ssa disks on our TSM > > server. The reason SAN attached storage gives poor performance is the > > size of the disks. You now have just a few large disks for your > > database, while in the past you probably had a few more smaller disks to > > hold the same amount of data. Disk seek times have not kept pace with > > disk size, so while the disks are a lot bigger, they take about the same > > amount of time to find a block of data. Since almost each database read > > access requires a seek, more spindles give more bandwith and this better > > performance. Even worse in raid5, since now all disks must have read the > > block of data before the raid5 controller can return anything. > > > > Raid5 will give you another performance hit, especially if you have a > > write-trough cache (or no cache at all) and not a write back cache. > > > > You probably want to look into the cache-hit ratio on the raid5 > > controller, and see how you could improve that. Other than that, I still > > feel jbod is the way to go for databases. More spindles are more > > better... ;) > > > > > I have called it in to Tivoli support but has yet to get a callback. > > > Has anyone noticed that support is now very non-responsive? > > > > > > > > > > > > server; AIX 4.3.3, TSM 4.2.1.15 > > > > > > Thanks, > > > Eliza Lau > > > Virginia Tech Computing Center > > > 1700 Pratt Drive > > > Blacksburg, VA 24060 > > > [EMAIL PROTECTED] > > > > > --- > > Met vriendelijke groeten, > > > > Remco Post > > > > SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl > > High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167 > > PGP keys at http://home.sara.nl/~remco/keys.asc > > > > "I really didn't foresee the Internet. But then, neither did the > computer > > industry. Not that that tells us very much of course - the computer > > industry > > didn't even foresee that the century was going to end." -- Douglas Adams > > >
