Nelson, Doug wrote:
>When I run a Query Storage Group ( Q stg) on the Disk Pool, I get the following
>(puzzling) results
>
>Name: Diskpool
>Device: Disk
>Capactity: 15 gig
>Pct Util: 92.1
>Pct Migr: 54.2
>High Mig: 70
>Low Mig: 40
>
> My question is, If my Migration parameters are 70/40 (and there is no migration in
>progress) why do I have a 92% utilized and a 54% migrated? I just had the thought
>that this could be because we have caching turned on. Is this correct?
>
> As a side note, has anyone had problems with caching slowing things down rather
>than speeding them up?
>
> Thanks, Doug
>
>Douglas C. Nelson
>Distributed Computing Consultant
>Alltel Information Services
>Chittenden Data Center
>2 Burlington Square
>Burlington, Vt. 05401
>802-660-2336
>
>
Doug,
The "Pct Util" value show the percetage of the storage pool that has
vailid data in it. The "Pct Migr" shows what percentage is eligable to
be migrated, i.e. if this value were higher thatn "High Mig". Now the
real answer to your question is what is eligiable for migration, any
filespaces that have not previously been migrated ( that would imply
that caching was on) and that filespace meets the migration delay
attributes ("MIGDelay" and "MIGContinue") of your storage pool.
In regards to performance with cache turned on, yes that can impact
performance. Enabling "CACHe" on a storage pool will improve the
performance of a restore since you may be able to retreive some or all
of you files from the diskpool without going to tape. However, this
does come at a price. When "CACHe" is enabled you normal write
operations to that diskpool can be slowed dramaticaly. This is due to
increased DB and LOG activity in order to maintain the cached file
information. What is happening is when a file is being stored in the
diskpool and there is no more free space for it then ITSM must remove
one or more cached files to make space for the new file. Obviously
there is no need to physically remove the cached files from the storage
pool, but ITSM must remove the DB entry for this file. Needless to say
this can cause a large amount of DB thrashing as well as increased
utilization of the LOG. Your actually performance hit can vary based on
how well your DB and LOG is tuned.
I hope that covers it in enough detail for you. You can probably get
several different opinions on whether or not to use "CACHe" enabled
storage pools. You simply have to decide if the trade offs are in your
favor.
--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.
===============================================================================
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education
IBM Certified Advanced Technical Expert, CATE
AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
Red Hat Certified Engineer, RHCE
===============================================================================
