Re: [ADSM-L] DB Bufferpool sizing - continued
2008-04-29 09:25:40
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
|
|
|