ADSM-L

Re: ADSM and 3590 Performance on RS6000 S7A?

1999-06-07 15:14:07
Subject: Re: ADSM and 3590 Performance on RS6000 S7A?
From: Dwight Cook <decook AT AMOCO DOT COM>
Date: Mon, 7 Jun 1999 14:14:07 -0500
     Now we buffer all our data to diskpools first, then I see about 28
     GB/hr bleeding the diskpool to tapepool.

     just a FYI...

     later,
           Dwight


______________________________ Reply Separator _________________________________
Subject: Re: ADSM and 3590 Performance on RS6000 S7A?
Author:  terence.louis (terence.louis AT USAA DOT COM) at unix,mime
Date:    6/7/99 11:01 AM


Mark,

        The throughput you are getting seems too low.  We are seeing 4
MB/Sec to 7 MB/sec backing up AIX clients across an ATM network to a ADSM
v3.1.2.20 server running on a RS/6000-S7A with 3590 tape drives.  What
version of the ADSM server are you running, and what parameters do you have
configured in your dsmserv.opt server and dsm.sys client files?

Terence

        -----Original Message-----
        From:   Mark Rinfret [SMTP:mrinfret AT MARKRINFRET DOT COM]
        Sent:   Saturday, June 05, 1999 9:10 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        ADSM and 3590 Performance on RS6000 S7A?

        I'm in the process of configuring and testing ADSM and a 3590 tape
drive
        with autochanger on an RS/6000 S7A system. The tape drive is
connected to a
        SCSI F/W adapter. The server and client are both on the same machine
and I'm
        using the SHAREDMEM communication method. I've also set the buffer
sizes and
        vmtune parameters recommended by the performance guide. However,
when I run
        a test archive (a half-dozen filesystems totalling around 2.5 GB), I
see an
        aggregate throughput rate of about 2 MB / second and I hear lots of
        start/stop activity on the drive. I expected much better performance
than
        this.

        I'd appreciate hearing from others who have a similar configuration
and who
        might have suggestions on tuning this as well as real data on the
throughput
        rates I should expect.

        Thanks,

                Mark Rinfret