Hey,
I'm having a really wierd problem. We just installed 4 ADSM 3.1.2.40
servers on 4 Sun E6000 Solaris 2.6 servers.
Each server has 10-12 CPUs and 5GB RAM. We have a 90GB diskpool assigned to
each ADSM server. The
diskpool is made up of 4 20GB files and one 10GB file on one file system. A
disk pool migration on server4
started at 04:00 on April 11, and had migrated 24GB in 40 hours. The three
other Solaris ADSM servers
normally move about 10 GB per hour (see a migration on server3 below).
Another migration on server4
(after we stopped and started ADSM) moved 6GB in 9 hours. Server4's
slowness is causing havok
with our DB backups because they dump about 40GB daily per ADSM server.
We normally backup large databases directly to tape, but we were short on
tape devices and decided
to try the diskpool approach.
IBM tech support said that it might be a SQL-Backtrack ADSM OBSI module
incompatilibity, but the
research we did into that angle turned up fruitless. An AIX ADSM server,
server3 and server4
all share the same 3494 library. Each is assigned 3 3590E drives inside the
same library. Private/Scratch
categories are 300/301, 310/311 and 320/321 respectively. Servers3/4 mainly
handle database backups
from Sybase via SQL-Backtrack. Servers3/4 have one SQL-Server installed
locally, and others remotely.
They were all able to send data into the diskpool without any problems.
Server4 is having problems
moving data off the diskpool (obviously !). What can I look at to figure
out why server4 is taking so long ?
Thanks, Aubrey Truex
FedEx Services
Date/Time Message
--------------------
----------------------------------------------------------
04/12/00 03:55:37 ANR0984I Process 381 for MIGRATION started in the
04/12/00 03:55:37 ANR0984I Process 381 for MIGRATION started in the
BACKGROUND at 03:55:37.
04/12/00 03:55:37 ANR1000I Migration process 381 started for storage pool
DISKPOOL01.
04/12/00 12:08:07 ANR1001I Migration process 381 ended for storage pool
DISKPOOL01.
04/12/00 12:08:07 ANR0986I Process 381 for MIGRATION running in the
BACKGROUND processed 1684 items for a total of
89,063,493,632 bytes with a completion state of
SUCCESS
at 12:08:07.
* server4.opt (the one that is having problems)
# more server.opt
COMMmethod TCPIP
commmethod http
TCPport 31000
httpport 31020
MSGINTerval 1
MAXSessions 40
BUFPoolsize 131072
LOGPoolsize 8192
TXNGroupmax 256
COMMTimeout 14400
IDLETimeout 60
EXPInterval 0
VOLUMEHistory /adsm4-home/volhist.server4.data
DEVCONFig /adsm4-home/devconfig.server4.data
MOVEBatchsize 1000
MOVESizethresh 500
enable3590library yes
* server3.opt (The other Solaris server that shares the library with server4
and works fine)
# more server3.opt
COMMmethod TCPIP
COMMmethod HTTP
TCPport 31000
HTTPport 31020
MSGINTerval 1
MAXSessions 40
BUFPoolsize 32768
LOGPoolsize 4096
TXNGroupmax 256
COMMTimeout 7200
IDLETimeout 30
EXPInterval 0
VOLUMEHistory /adsm3-home/server3.volhist.data
DEVCONFig /adsm3-home/server3.devconfig.data
MOVEBatchsize 1000
MOVESizethresh 500
ENABLE3590LIBRARY yes
|
