Hi,

did you look at the XE Toolkit:

 http://www.captivemetrics.com/Captive_Metrics/XE_Toolkit.html

?

 Rainer


----------------------------------------------------------------------


On Tue, 29 Apr 2008, Zoltan Forray/AC/VCU wrote:

 > All disk are internal.  We needed quantity vs speed (more for the LZ than
 > DB) so we didn't have a choice (Dell) other than the big SATA drives
 > (biggest SAS was around 300GB).
 > 
 > Unfortunately (please correct me if I am wrong) there doesn't seem to be
 > any really good, all inclusive system monitoring tools for Linux (I miss
 > Omegamon!)
 > 
 > 
 > 
 > Andy Huebner <Andy.Huebner AT ALCONLABS DOT COM>
 > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
 > 04/28/2008 03:56 PM
 > 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
 > 
 > 
 > 
 > 
 > 
 > 
 > 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.
 > 

--------------------------------------------------------
ProteoSys AG
Carl-Zeiss-Straße 51
55129 Mainz

Dr. Rainer Schöpf
Leiter Software/Softwareentwicklung

Mail:   rainer.schoepf AT proteosys DOT com
Phone:  +49-(0)6131-50192-41
Fax:    +49-(0)6131-50192-11
WWW:    http://www.proteosys.com/
--------------------------------------------------------
ProteoSys AG - Carl-Zeiss-Str. 51 - D-55129 Mainz
Amtsgericht Mainz HRB 7508 - USt.-Id Nr.: DE213940570
Vorstand: Helmut Matthies (Vorsitzender), Prof. Dr. André Schrattenholz
Vorsitzender des Aufsichtsrates: Dr. Werner Zöllner