> I would suggest doing an iostat while your backup stgpool is running, and
> look for I/O busy time and I/O waits on your DB and log volumes. Even
> with physical mirroring, you can get a LOT of I/O wait in the DB & logs;
> remember that every tiny thing that gets copied on a backup stgpool will
> requre a DB read, a log write, and a DB write (at the very least).
>
> Also do Q DB F=D and check the buffer pool cache hit %. Low buffer pool
> cache hit% is known to cause sluggishness.
>
> Another thing you could do: Back up something big directly to tape. Does
> that get the same throughput?
> If it goes faster, then your slowdown probably has something to do with
> your disk subsystem, or with the ADSM Db or logs, not the tape.
>
> The other thing you can do, if you suspect the tape drivers are the issue,
> is take ADSM out of the picture altogether:
>
> Take a tape drive offline to ADSM (or shut down ADSM).
> Mount a cartridge manually, and tar something big to it from AIX.
> (If you can't find something else big, shut down ADSM and copy one of the
> stgpool volumes.)
>
> That takes the ADSM DB, log, etc. out of the picture.
> If you get about the same throughput rate, it's could be in the tape
> hardware.
> If you get a drastically higher throughput then you know your contention
> is likely an ADSM tuning issue.
>
> Hope that helps..
> ************************************************************************
> Wanda Prather
> The Johns Hopkins Applied Physics Lab
> 443-778-8769
> wanda_prather AT jhuapl DOT edu
>
> "Intelligence has much less practical application than you'd think" -
> Scott Adams/Dilbert
> ************************************************************************
>
>
>
>
> -----Original Message-----
> From: John Schneider [SMTP:jdschn AT ATTGLOBAL DOT NET]
> Sent: Wednesday, March 08, 2000 11:36 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Performance problem with DLT drives
>
> Greetings,
> I am talking big performance problems here, as in 1.5MB/sec per
> drive, as opposed to the stated 9MB/sec we would expect. Something has
> gone awry, and I can't see what.
> I have a customer with 6 DLT drives in a STK9714 attached to a
> RS/6000 S7A. The S7A is running AIX 4.3.2 with fairly recent
> maintenance and microcode updates (I believe). It has 10GB of memory and
> 8 processors. It is running ADSM 3.1.2.42. Specifically, it is
> running:
>
> adsm.afs.client.aix42 3.1.20.5 C ADSM Client - AFS File
> Backup
> adsm.api.client.aix42 3.1.20.7 C ADSM Client - Application
> adsm.butaafs.client.aix42
> adsm.butadfs.client.aix42
> adsm.client.aix42.base 3.1.20.7 C ADSM Client -
> Backup/Archive
> adsm.client.aix42.common 3.1.20.7 C ADSM Client - Common Files
> adsm.client.aix42.hsm 3.1.20.7 C ADSM Client - Hierarchical
> adsm.devices.NetTAPE-tlc 3.1.2.0 C ADSM Device Support for
> NetTAPE
> adsm.devices.acsls 3.1.2.20 C ADSM Device Support for ACS
>
> adsm.devices.rte 3.1.2.42 A ADSM Device Support runtime
>
> adsm.dfs.client.aix42 3.1.20.5 C ADSM Client - DFS File
> Backup
> adsm.html.en_US.clients.data
> adsm.html.en_US.server.data
> adsm.html.en_US.unix.data 3.1.0.6 C ADSM Online Library, UNIX
> Client
> adsm.license.rte 3.1.2.0 C ADSM Server License
> Registration
> adsm.msg.en_US.emhelp 3.1.2.0 C ADSM EM Panel Help - US
> English
> adsm.pdf.en_US.clients.data
> adsm.pdf.en_US.server.data
> adsm.pdf.en_US.unix.data 3.1.0.6 C ADSM Online Library, UNIX
> Client
> adsm.server.gif 3.1.2.20 C ADSM Server Web
> Administrator
> adsm.server.rte 3.1.2.42 A ADSM Server Runtime
> adsm.server.util 3.1.2.20 C ADSM Server Utilities
> adsm.web.client.aix42 3.1.20.5 C ADSM Client - WebClient
> adsm.webcli.client.aix42 3.1.20.7 C ADSM Client -
> Backup/Archive WEB
>
> For some time now, we have been getting only about 1.5MB/sec to each of
> the DLT drives. Each is on it's own differential SCSI bus. They are
> defined as /dev/mtX, using the smit devices/ADSM devices, so they are
> using the ADSM drivers for the DLTs. According STK, the tape drives and
> the library all have the most recent microcode updates.
>
> The performance of the network or clients is not involved in this
> problem, since the rate of 1.5MB/sec holds true even for things like
> 'backup stgpool' commands. Yesterday, for instance, we did a backup
> stgpool maxpr=2, so there were two drives being read, and two being
> written to. We copied 72GB in about 7 hours. That works out to 5.14 GB
> per hour per drive being written to, or 1.46MB/sec per drive. That is
> just ridiculously slow. There was a time (4-6 months ago) when the
> performance was about 4.5-5.5MB/sec on the same drives, but they can't
> see anything that changed drastically to account for it. However, they
> were at ADSM 3.1.2.20 back then, and upgraded to .42 in an attempt to
> solve a problem with occasional error in the tape library. I don't
> think this change can be implicated all by itself, otherwise they would
> have noticed it right away. I am not out there on a daily basis.
>
> The S7A is fairly CPU constrained, but not memory constrained. Paging
> is almost never. The performance seems to be about the same no matter
> what time of day or night, so I have trouble believing the S7A is the
> culprit, otherwise performance for all other processing would be very
> slow, and that is not the case.
>
> In the dsmserv.opt file, we have set:
>
> BUFPoolsize 131072
> LOGPoolsize 8192
> MIRRORRead DB Normal
> MIRRORWrite DB Sequential
> MIRRORRead LOG Normal
> MIRRORWrite LOG Parallel
>
> which it seems like to me are the only ones that should affect
> performance of a 'backup stgpool', since the network isn't involved at
> that point. Bufpool is set high because the system has plenty of
> memory.
>
> The ADSM database about (4GB) is on it's own pair of disks (mirroring
> at the ADSM level), and so is the ADSM log (about 1.5GB), so there
> doesn't seem to be much contention at the ADSM database level or log
> level.
>
> Thanks in advance for any advice,
>
> John Schneider
>
> ***********************************************************************
> * John D. Schneider Email: jdschn AT attglobal DOT net * Phone: 636-349-4556
> * Lowery Systems, Inc.
> * 1329 Horan Disclaimer: Opinions expressed here are
> * Fenton, MO 63026 mine and mine alone.
> ***********************************************************************
|
