- 1. ADSM Server Selection (score: 1)
- Author: Peter Talajic <pmt2f AT UOTTAWA DOT CA>
- Date: Thu, 5 Sep 1996 09:15:19 -0400
- Hello everyone. At the University of Ottawa, we are in the process of selecting some new equipment to run our ADSM server. Currently, we have about 90-gig of data stored in backups. The current serve
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00048.html (12,169 bytes)
- 2. Re: ADSM Server Selection (score: 1)
- Author: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
- Date: Thu, 5 Sep 1996 09:46:15 EDT
- No, but it appears that ADSM allocates database space all from one volume, before allocating space on the next volume. I.e., it does not appear to use a round-robin algorithm, which would have been n
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00049.html (11,638 bytes)
- 3. Re: ADSM Server Selection (score: 1)
- Author: Francisco Reyes <reyes01 AT IBM DOT NET>
- Date: Thu, 5 Sep 1996 12:06:25 -0400
- We have had 8MMs for a long time using them with software other than ADSM. With ADSM we got a DLT. DLTs seem to be much faster and so far no problems. The capacity DLTs can store is also usually high
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00053.html (11,434 bytes)
- 4. Re: ADSM Server Selection (score: 1)
- Author: Francisco Reyes <reyes01 AT IBM DOT NET>
- Date: Thu, 5 Sep 1996 12:22:30 -0400
- I have never used RS/6000s, but I am sure it must have some type of RAID. Try to get RAID 5 or any RAID with stripping. From reading this list, and my own experience, it seems the ADSM databases and
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00054.html (12,964 bytes)
- 5. Re: ADSM Server Selection (score: 1)
- Author: "Pittson, Timothy ,Corp,US" <tpittson AT HIMAIL.HCC DOT COM>
- Date: Thu, 5 Sep 1996 14:10:09 -0400
- 2) I've had good luck putting the database on a 7137 disk array (RAID-5) and the recovery log (mirrored) and disk storage pools on SSA disks. I'd definitely try to keep the database, recovery log, an
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00059.html (14,091 bytes)
- 6. Re: ADSM Server Selection (score: 1)
- Author: Andreas Floeter <Andreas.Floeter AT AIRBUS DOT DE>
- Date: Fri, 6 Sep 1996 09:57:18 +0200
- Your throughput is (8*1024)/(40*60) = 3.413 MB/sec. That is 1/3 of the theoretical performance of the drives. To which degree is your database filled? Have you seen faster values? We are considering
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00081.html (15,592 bytes)
- 7. Re: ADSM Server Selection (score: 1)
- Author: Sheelagh Treweek <sheelagh.treweek AT COMPUTING-SERVICES.OXFORD.AC DOT UK>
- Date: Fri, 6 Sep 1996 09:37:01 +0100
- The very best performance we get is about 5 MB/sec on BACKUP STG with a large average filesize (greater than 1 MB). The very worst is about 1 MB/sec on MIGRATION with a very low average filesize (les
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00082.html (13,500 bytes)
- 8. Re: ADSM Server Selection (score: 1)
- Author: Andreas Floeter <Andreas.Floeter AT AIRBUS DOT DE>
- Date: Fri, 6 Sep 1996 13:50:18 +0200
- Currently, we use an Exabyte EXB-480 with 4 EXB-8505XL. We get 1.5GB database backed up in 17min, 1.5*1024/(17*60)=1.505. This figure can only be explained since the database is filled by 50%. We als
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00083.html (12,517 bytes)
- 9. Re: ADSM Server Selection (score: 1)
- Author: David Ong <david AT BABYONG.NSC DOT COM>
- Date: Fri, 6 Sep 1996 09:53:17 -0700
- Hi Andreas, The only advantage you are going to get with 3590s is storage density. Based on our own benchmarks running on AIX 4.1 on a 950, there is practically no speed advantage to be gained from t
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00093.html (11,452 bytes)
- 10. Re: ADSM Server Selection (score: 1)
- Author: ADSM Mailing list <adsm-l AT MUSTARD.SPICERACK.IBM DOT COM>
- Date: Tue, 10 Sep 1996 13:06:51 -0400
- That's to be expected, since writing lots of small files is less of a hassle than writing a few large files. Also, fewer files means lower ADSM database utilization. Exactly, since the client has to
- /usr/local/webapp/mharc-adsm.org/html/ADSM-L/1996-09/msg00137.html (11,768 bytes)
This search system is powered by
Namazu