ADSM-L

Re: [ADSM-L] DB Bufferpool sizing - continued

2008-04-29 06:11:23
Subject: Re: [ADSM-L] DB Bufferpool sizing - continued
From: CAYE PIERRE <Pierre.Caye AT ALCATEL-LUCENT DOT FR>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Apr 2008 11:44:40 +0200
AIX 5.3
DS4700 Disks
TSM 5.3.4.2
TSM Databases are not mirrored
TSM DB Disks are equally configured, LUNs are 36Gb size
LOGS are mirrored, LUNs are 14Gb size
Buffpool is setup at about 25% of memory, SELFTUNEBUPOOLSIZE YES

                                                DAILY   
DB              Db                              EXPIRATION      
% USED  SIZE (GB)       USED PAGES      DURATION        MAIN BACKUP ACTIVITY
77%             110             21,926,224      00:18           large DB 
backups (>2Tb)
73%             180             33,832,344      01:06           Large DB 
backups (=>2Tb) and few but annoying very large incremental backups (>5,000,000 
files/day/client)
91%             80              18,768,228      01:07           Average DB 
backups (<2Tb) and homebrand archiving tool (numerous files)
90%             90              20,779,928      00:41           windoze backups
93%             120             28,825,772      00:13           windoze backups
9%              30              757,418 <0:01           special DMZ backups
30%             10              756,259 <0:10           Large mail databases 
backups

As you can see, results are very different and depend mainly on the number of 
objects to manage.

Regards

Pierre


> -----Message d'origine-----
> De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De 
> la part de Andy Huebner
> Envoyé : lundi 28 avril 2008 21:53
> À : ADSM-L AT VM.MARIST DOT EDU
> Objet : Re: [ADSM-L] DB Bufferpool sizing - continued
> 
> Expiration has more to do with disk speed than CPU power.  
> Have you looked at your disk performance?
> Our DB is 120GB @ 89% and is on 14 FC drives (as presented 
> from the disk array).  The log is on a separate drive.  The 
> DB and logs are also mirrored to a different array, same 
> configuration.
> Expire times 3-5 hours.
> Buffer Pool pages 524,288 @ about 99.1% hit rate.
> 
> Andy Huebner
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 
> On Behalf Of Zoltan Forray/AC/VCU
> Sent: Monday, April 28, 2008 12:15 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] DB Bufferpool sizing - continued
> 
> We tried to go RAW and I don't think we could. Can't remember 
> why - I think it has to do with RH Linux restrictions.
> 
> The DB are mirrored across two disk subsystems/controllers. 
> The primary copy is on internal 500GB SATA RAID-1 drives (DB, 
> OS and Logs only) and the mirrors on an 8-drive 750GB SATA 
> RAID-5 sharing the 4TB backuppool LZ.
> 
> Here is the last expire.
> 
> 04/26/2008 08:00:17  ANR0984I Process 92 for EXPIRE INVENTORY 
> started in the BACKGROUND at 08:00:17 AM. (SESSION: 36385, 
> PROCESS: 92)
> 04/28/2008 00:56:26  ANR0987I Process 92 for EXPIRE INVENTORY 
> running in the BACKGROUND processed 5579839 items with a 
> completion state of SUCCESS
> at 12:56:26 AM. (SESSION: 36385,                      PROCESS: 92)
> 
> Here is one of the longer runs:
> 
> 03/22/2008 11:00:06  ANR2750I Starting scheduled command 
> EXPIRE_INVENTORY (EXPIRE INVENTORY ). (SESSION: 60470)
> 03/24/2008 09:47:34  ANR0987I Process 485 for EXPIRE 
> INVENTORY running in the BACKGROUND processed 1141005 items 
> with a completion state of SUCCESS
> at 09:47:34 AM. (SESSION: 60470,                       PROCESS: 485)
> 
> 
> 
> 
> "Mueller, Ken" <KMueller AT MCARTA DOT COM>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 04/28/2008 11:45 AM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 
> 
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
> 
> Subject
> Re: [ADSM-L] DB Bufferpool sizing - continued
> 
> 
> 
> 
> 
> 
> Zoltan-
> 
> We also run TSM on a dedicated Linux/Intel, although on a 
> smaller scale than you.  The server has 2.5GB RAM and two 
> 2GHz Xeons.  Our DB is 23G of which 70% is in use. Buffer 
> pool is set at 32M (8192 pages) with selftune on. Expiration 
> is run daily - typically completes in 4-7 minutes!
> 
> I'm curious why your experience is vastly different.  Are 
> your db volumes part of a file system or raw volumes?  Ours 
> are file system volumes (ext3).  Given Linux's propensity for 
> using unallocated RAM as file system cache and the generous 
> memory this server has, a significantly higher number of DB 
> pages may be in memory than meets the eye.  Using raw volumes 
> bypasses this caching. Perhaps the Linux file system cache 
> management is more efficient than the TSM buffer pool 
> management - maybe the adage 'less is more' in terms of TSM 
> buffer pool applies here?
> 
> How many objects get processed during your expiration runs?  
> We're in the magnitude of 10s of thousands of objects.
> 
> -Ken
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 
> On Behalf Of Zoltan Forray/AC/VCU
> Sent: Monday, April 28, 2008 10:41 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: DB Bufferpool sizing - continued
> 
> 
> Pertaining to the recent discussion of buffpool sizing 
> (larger vs smaller
> - cpu usage, etc) I would like to get some opinions.
> 
> I followed the discussion and was aware of the issue of going 
> too large and killing any benefits by increased CPU usage and such.
> 
> So, I have been experimenting.
> 
> My big Linux TSM server has 8GB RAM and is dedicated to TSM, 
> so other products using/sharing the memory is not an issue.  
> The TSM DB is 160GB assigned with 77% used.
> 
> The buffpoolsize (with selftune) was set to 768MB.
> 
> I just bumped it to 1GB (still at the 1/8 of real memory 
> guideline) to see if it would improve things, using EXPIRE 
> INVENTORY as a benchmark and trying to ignore the "Cache 
> hit%" value (which I could never keep at or above 99%).
> 
> Before the change, I was seeing EXPIRE INVENTORY running 46-51 hours.
> 
> This past weekend, it ran 40H.
> 
> I realize that having only 1-test result after the change is 
> hardly a good indicator of either positive or negative results.
> 
> So, my question is this.
> 
> Do I bump it to 1.25-1.5GB (still well below the "guidelines" 
> of 1/8-1/2 of real memory) and see if that improves things 
> even more or do I drop down to 512MB to see if it improves 
> things even more than the memory increase?
> 
> Anyone else willing to share their DB sizes/buffpool/expire 
> inventory durations?
> 
> Open to all thoughts (besides the need for another TSM 
> server......this is already in the works and we have stopped 
> adding new nodes to this server).
> 
> 
> This e-mail (including any attachments) is confidential and 
> may be legally privileged. If you are not an intended 
> recipient or an authorized representative of an intended 
> recipient, you are prohibited from using, copying or 
> distributing the information in this e-mail or its 
> attachments. If you have received this e-mail in error, 
> please notify the sender immediately by return e-mail and 
> delete all copies of this message and any attachments.
> Thank you.
>