ADSM-L

Re: Backup Storage Pool Process Ending Early

2000-04-20 17:27:36
Subject: Re: Backup Storage Pool Process Ending Early
From: "Cook, Dwight E" <cookde AT BP DOT COM>
Date: Thu, 20 Apr 2000 16:27:36 -0500
OK, I see what the question was now...  and with that I can't say...
We could find out though... it is just in the selection method of the
copy/backup processes that is making some finish earlier than others...
do you collocate your copy pool ?  if so you could check the output volumes
from each process (via query content) to see what node's data is being
written by each process to see if it is just taking all the nodes (say 20)
and assigning an even number (5) to each backup/copy process... and then
random chance might be having the 5 nodes assigned to the 1st process are
all small NT servers and all 5 assigned to the last process are all BIG unix
DB servers...

I would say by what you have seen already that the processes don't split up
the work based on MB to process...

I'm betting this is like migration processes... when the processes start
they grab "chuncks" of work bound at least by node but a single process
might line up multiple nodes (lock into processing a node's data which will
not allow another mig. pro. to process it) then when those processes finish
the pool is re-evaluated to see if more processes should be started to get
it on down below the current "low" limit.... now it re-evaluates because
more inbound data can be  dumped in during migrations...   it would be real
hard to sayif initally the incremental is "locked in" and if any data that
comes into the primary pool once the backup stgpool begins gets pushed that
day to the copy pool or if it hits it the next day ???

Sounds like a lot of work to determine what really happens but if someone
already knows the logic of the processing I'd like to know it also.

Dwight

> ----------
> From:         Andy Carlson[SMTP:andyc AT ANDYC.CARENET DOT ORG]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Thursday, April 20, 2000 4:08 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Backup Storage Pool Process Ending Early
>
> I don't think this answers my question.  We are putting bout 260GB per
> night into the storage pool.  My sequence of processes is to backup the
> disk pool to copypool. migrate, backup the tape pool to copypool in case
> I missed anything, then backup the database.  I understand that each
> process is not limited to one node, so then why are the first three
> processes ending so quickly?
>
> Andy Carlson                             |\      _,,,---,,_
> andyc AT andyc.carenet DOT org            ZZZzz /,`.-'`'    -.  ;-;;,_
> BJC Health System                       |,4-  ) )-,_. ,\ (  `'-'
> St. Louis, Missouri                    '---''(_/--'  `-'\_)
> Cat Pics: http://andyc.dyndns.org/animal.html
>
> On Thu, 20 Apr 2000, Cook, Dwight E wrote:
>
> > Remember what a "backup stgpool" is doing... is it performing an
> > "incremental" against the primary storage pool...
> > Now does this server have the seen (about) 260 GB nightly into the
> primary
> > pool ? ? ?
> > any given process isn't limited to processing only one node's data...
> > now if your primary pool here is only taking in 100 GB/night now there
> would
> > be reason to worry!
> >
> > Dwight
> >
> > > ----------
> > > From:         Andy Carlson[SMTP:andyc AT ANDYC.CARENET DOT ORG]
> > > Reply To:     ADSM: Dist Stor Manager
> > > Sent:         Thursday, April 20, 2000 3:44 PM
> > > To:   ADSM-L AT VM.MARIST DOT EDU
> > > Subject:      Backup Storage Pool Process Ending Early
> > >
> > > I think this was discussed recently, but unfortunately, I did not
> think
> > > it applied to me, so I didn't read it and I can't find it in the
> > > maillist archive.  I start my backup stgpool primary-disk-pool
> copyppol
> > > maxpr=4 at 6:00am.  The 4 processes did the following and ended at the
> > > following times:
> > >
> > > process1       29,755,260,928      07:11
> > > process2       37,418,749,952      07:27
> > > process3       61,774,635,008      08:16
> > > process4      133,995,388,928      10:34
> > >
> > > I do not believe I have any one node that backs up 72GB or more of
> data,
> > > so I don't think that last process is chunking away on one node.  What
> > > could be happening here?  Thanks for any info.
> > >
> > > Andy Carlson                             |\      _,,,---,,_
> > > andyc AT andyc.carenet DOT org            ZZZzz /,`.-'`'    -.  ;-;;,_
> > > BJC Health System                       |,4-  ) )-,_. ,\ (  `'-'
> > > St. Louis, Missouri                    '---''(_/--'  `-'\_)
> > > Cat Pics: http://andyc.dyndns.org/animal.html
> > >
> >
>
<Prev in Thread] Current Thread [Next in Thread>