>Please, look at this tape mount problem an tell me what I'm
>doing wrong.
I would suspect nothing. Can you determine if your disk storage pool filled
because if so, clients would fail to write to disk stg and go straight
to tape. You would then be bounded by the number of tape decks - ie one
tape for migration, and one for each active client.
We have seen this behaviour (last night - coincidently) on our AIX server.
We have 8GB stg pool for backup; last night we received 10GB data into that
pool and it took 10hours to migrate to tape (a single mig process, to a 3590
deck). We believe the DB performance is the bottleneck. The number of files
transferred was just over 200,000. As this is the start of our project and we
have only 89 registered clients out of a possible 8000 entitled to use this
service, I am a worried person. Last night we brought on line just 4 large
unix servers (in addition to incrementals for existing clients). We typically
see 10% peak utilisation of out FDDI backbone; cpu on the R24 is often showing
80-90% kernel wait, whislt the DB disks show maybe 50 transactions/sec.
Our DB is currently 40% used of 1.7GB; recovery log is 2GB on a separate disk.
[Disks are SSA; 4 adapters shared by tw0 machines; no one path is longer
than 2 disks.]
I think we are i/o bound on the DB. If anyone has any advice, I'd be very
grateful. We have tried the DB on a dedicated disk and spread over several
disks.
Thanks for your time. Regards,
Sheelagh Treweek Email: sheelagh.treweek AT oucs.ox.ac
DOT uk
Oxford University Computing Service Tel: +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, Uk Fax: +44 (0)1865 273275
------------------------------------------------------------------------------
=========================================================================
|
