RE: Determine bottlenecks during backup

John,

The virtual tape itself doesn't support compression.

However, I can force OS/400 to handle the compression by doing
USEOPTBLK(*NO) DTACPR(*YES) COMPACT(*NO).

During my tests, having OS/400 handle compression took 56% longer than
without (a 22.4GB library in 297s vs. 465s). 

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jones, John (US)
> Sent: Wednesday, March 01, 2006 2:20 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Determine bottlenecks during backup
> 
> It was a 2-way 570 with 16GB RAM and 54 70GB 15K disks.  48 disks in 4
> 0595s with 2757s and the remaining 6 disks in the CEC with 
> the base RAID
> card.
> 
> The machine has since been LPARed and had more RAM added to handle the
> multiple WAS instances.  I haven't run any more benchmarks as we moved
> to BRMS & save-while-active for most stuff so tape 
> performance is mostly
> a non-issue now. 
> 
> As I recall at COMMON last year IBM noted about 235-250GB/hour as a
> potential speed on SCSI-attached LTO3s.  I figure slightly better than
> average compression would explain how I'm exceeding what IBM noted.
> 
> Speaking of which, what compression are you using?
> 
> John A. Jones, CISSP
> Americas Information Security Officer
> Jones Lang LaSalle, Inc.
> V: +1-630-455-2787 F: +1-312-601-1782
> john.jones@xxxxxxxxxx
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
> Sent: Wednesday, March 01, 2006 12:59 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Determine bottlenecks during backup
> 
> John,
> 
> Quick question, what type of hardware set up do you have that you're
> getting 275MB/s with an LTO3 drive connected to a 5702?
> 
> Specifically, I'm wondering about CPU/RAM and Disk subsystem.
> 
> As I run some test saves on a single rather large library, I'm seeing
> average disk usage going from an idle of 1% up to about 20% 
> with a spike
> to 40%.  I'm wondering if this is an indication that my disk subsystem
> is the bottleneck.  
> 
> I know that 40% is a magic number for disk utilization, but for the
> purpose of a save I expect disk utilization to be higher if it was the
> bottle neck.
> 
> Thoughts?
> 
> Thanks,
> 
> 
> Charles Wilt
> --
> iSeries Systems Administrator / Developer Mitsubishi Electric 
> Automotive
> America
> ph: 513-573-4343
> fax: 513-398-1121
>   
> 
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx 
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
> Jones, John (US)
> > Sent: Thursday, February 23, 2006 11:35 AM
> > To: Midrange Systems Technical Discussion
> > Subject: RE: Determine bottlenecks during backup
> > 
> > What kind of tape drive?
> > 
> > The SCSI interface in this case is very likely not the bottleneck; 
> > I've got 5702s that are doing about 275MB/s (compressed) with LTO3 
> > drives.
> > That leaves the potential bottlenecks as:
> > 
> > 1. Tape drive.  If LTO2 or LTO3, this should not be the bottleneck 
> > unless the drive is malfunctioning or dirty.
> > 2. System bus.  Could be the problem.  Where is bus 28?  If 
> not in the
> 
> > CEC, what type of tower?  I had LTO2 drives on our former 
> 830; one on 
> > a controller in the CEC and one in a migration tower (a former 720 
> > frame).
> > The drive on the controller in the CEC was significantly 
> faster (more 
> > than 2x) than the drive in the tower even though the drives 
> themselves
> 
> > were identical.
> > 3. System (CPU/RAM).  This is probably not the bottleneck 
> unless the 
> > partition is RAM-constrained.
> > 4. Disk subsystem.
> > 5. Object type.  Fewer-but-larger objects will save faster 
> than lots 
> > of small objects.  The more objects there are the higher the system 
> > overhead.
> > 6. Save type.  Turn on compression for the non-SAVSYS 
> pieces; you've 
> > got plenty of CPU to handle it.
> > 
> > Also, try to figure out which part of the 21 is taking a 
> lot of time.
> > Is it IFS, NONSYS, SAVSYS, etc.?  Easiest way is to look at the job 
> > log afterwards and look at the timestamps.
> > 
> > John A. Jones, CISSP
> > Americas Information Security Officer
> > Jones Lang LaSalle, Inc.
> > V: +1-630-455-2787 F: +1-312-601-1782
> > john.jones@xxxxxxxxxx
> > 
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
> > Sent: Thursday, February 23, 2006 10:02 AM
> > To: Midrange Systems Technical Discussion
> > Subject: Determine bottlenecks during backup
> > 
> > All,
> > 
> > I'm trying to evaluate the performance of our new backup system.
> > 
> > The tape device is rated at 200 MB/s and is attached to an 160MB/s 
> > 5702 SCSI card.
> > 
> > However, on my first test save menu option 21 save I saved 
> 238.7 GB of
> 
> > data (uncompressed) in about 90 minutes, a throughput of about 45 
> > MB/s.
> > 
> > The iSeries is a model 810 with 2700CPW of which 87% (2349CPW) is 
> > assigned to the primary partition being backed up.
> > 
> > System bus 1 has a 2757 Controller card with 12x4326 
> RAIDed.  Of those
> > 12 disks, the system ASP contains 10 disks, and a user ASP is 
> > configured with 2 disks.
> > 
> > System bus 28 has the 5702 controller card.
> > 
> > 
> > How can I tell if the save is bottlenecked by CPU, disk, 
> bus, or tape 
> > device?
> > 
> > Thanks,
> > 
> > Charles Wilt
> > --
> > iSeries Systems Administrator / Developer Mitsubishi Electric 
> > Automotive America
> > ph: 513-573-4343
> > fax: 513-398-1121
> >  
> > 
> > --
> > This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing
> 
> > list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, 
> > unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
> please take 
> > a moment to review the archives at 
> > http://archive.midrange.com/midrange-l.
> > 
> > 
> > 
> > This email is for the use of the intended recipient(s) only.  
> > If you have received this email in error, please notify the sender 
> > immediately and then delete it.  If you are not the intended 
> > recipient, you must not keep, use, disclose, copy or 
> distribute this 
> > email without the author's prior permission.
> > We have taken precautions to minimize the risk of transmitting 
> > software viruses, but we advise you to carry out your own 
> virus checks
> 
> > on any attachment to this message.  We cannot accept 
> liability for any
> 
> > loss or damage caused by software viruses.  The information 
> contained 
> > in this communication may be confidential and may be subject to the 
> > attorney-client privilege. If you are the intended 
> recipient and you 
> > do not wish to receive similar electronic messages from us in the 
> > future then please respond to the sender to this effect.
> > 
> > --
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, 
> > unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
> please take 
> > a moment to review the archives at 
> > http://archive.midrange.com/midrange-l.
> > 
> > 
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
> please take a
> moment to review the archives at 
> http://archive.midrange.com/midrange-l.
> 
> 
> 
> This email is for the use of the intended recipient(s) only.  
> If you have received this email in error, please notify the 
> sender immediately and then delete it.  If you are not the 
> intended recipient, you must not keep, use, disclose, copy or 
> distribute this email without the author's prior permission.  
> We have taken precautions to minimize the risk of 
> transmitting software viruses, but we advise you to carry out 
> your own virus checks on any attachment to this message.  We 
> cannot accept liability for any loss or damage caused by 
> software viruses.  The information contained in this 
> communication may be confidential and may be subject to the 
> attorney-client privilege. If you are the intended recipient 
> and you do not wish to receive similar electronic messages 
> from us in the future then please respond to the sender to 
> this effect.
> 
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>