Have you looked at dstat from Dag Wieers -
http://dag.wieers.com/home-made/dstat/

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, April 29, 2008 9:13 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: DB Bufferpool sizing - continued


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.