Hi Henrik,
unfortunately I don't have any specific recommendations for you situation, but
consider looking at some of these:
(our ADSM server is a silver node, 4-way, 2 GB memory)
The following are segments from an article that I'm writing, and hoping to get
published, if the information is bad or good please let me know!
1. example from my TSM (ADSM) server:
The biggest benefit I found is tuning vmtune. It is found in
/usr/samples/kernel/vmtune (if you have installed bos.adt.samples). The parameters
that I have changed are:
-r 'r' is the minimum number of pages that need to be read sequentially
before the VMM detects a sequential read. I have this set to 2.
-R to find to right setting for R, I used /usr/bin/filemon. First I set R
to an arbitrary large value, such as 128.
Then I started a filemon session and copied a large
sequential file to /dev/null. Next look at the filemon report for that LV contains the
filesystem:
example: from ADSM server node
VOLUME: /dev/dbdumps_lv description: /home/dbdumps
reads: 3356 (0 errs)
read sizes (blks): avg 194.3 min 8 max 256 sdev
90.6
read times (msec): avg 35.693 min 1.096 max 488.857 sdev
39.371
read sequences: 2835
read seq. lengths: avg 230.0 min 8 max 512 sdev
68.5
Notice that the min read blocks is 8 and the max is 256. Remember a
block is 512 bytes. So the max is actually 128k or 32 x 4k blocks.
Which means the maximum number of read ahead blocks
that will happen is 32. This number will be dependent on your adapter and your disks.
-f 'f' is the lower limit of free pages. When the free list hits this
number the VMM starts to free memory pages. IBM recommends that this number be:
120 x the number of CPU's you have. I would try
different combinations to see what gives you the best performance. Most of my boxes
have this set at 256.
-F 'F' is the upper limit of free pages. When the VMM is freeing pages
and hits this many free it stops. 'F' should be at least: f + R x 4096).
This guarantees that there will be enough free memory
for a large disk read. I follow this for all of my boxes.
-h Setting 'h' to '1' (one) will enforce maxperm. I had to set this on my
production nodes because they where using too much memory (8-10 GB)
for file caching, managing this amount of file cache
was causing the HACMP daemons to time out, causing HACMP to think the node had failed.
WARNING: DO NOT CHANGE THESE PARAMETERS ON THE FLY - especially on a
production machine, it may have disastrous results.
I recommend changing them in /etc/rc.local.
2. Queue depth
If you are using SSA disks and especially if you are using a RAID array check the
queue depth.
EX:
root@unxd:/>lsattr -El hdisk5
pvid 00011396f62aa5420000000000000000 Physical volume identifier
False
queue_depth 112 Queue depth
True
write_queue_mod 1 Write queue depth modifier
True
adapter_a ssa0 Adapter connection
False
adapter_b none Adapter connection
False
primary_adapter adapter_a Primary adapter
True
reserve_lock yes RESERVE device on open
True
connwhere_shad 139639D79D1F4CE SSA Connection Location
False
max_coalesce 0x20000 Maximum coalesced operation
True
size_in_mb 255117 Size in Megabytes
False
location Location Label
True
If the last column is 'True' then the value can be changed, if it is 'False',
then the information is for display only.
One parameter that I always check, especially with RAID arrays, is the
queue_depth.
This specifies the number of commands that can be outstanding against
the logical disk. It is very important with RAID arrays to make sure that this number
is:
the queue depth of an individual disk x the number of disks in the array.
In this example it is 8 x 14 or 112. It is not 16 disks because the
equivalent of one disk is used for parity and one hot spare.
3. Are you using LVM striping?
4. Are you using the fast write cache (FWC)?
5. Is your TSM database on the same disks as your disk storage pool? You may want to
separate them if they are.
6. other recommendations:
-put the busiest disks in the centre of the loop, to give the less active disks a
chance to transfer information
-when using RAID 1 or RAID 10, make sure that half the disks are closest to one port
and the other half of the disks are closest to the other port
-try not to put more than 32 disks per loop
-use the fast write cache, especially for RAID 5 array's
Our setup:
I have 16 SSA disks.
- 2 disks are configured as one RAID 1 array, in positions 1 and 16 in the I/O
drawer - equal distance from the adapter. This holds the ADSM database and log.
- 6 disks hold my disk pool (RAID 0)
- 8 disks hold a filesystem that is used to back Sybase databases. It is NFS mounted
to all the other nodes.
Let me know if I can help.
Miles
-------------------------------------------------------------------------------------------
Miles Purdy
System Manager
Farm Income Programs Directorate
Winnipeg, MB, CA
[EMAIL PROTECTED]
ph: (204) 984-1602 fax: (204) 983-7557
-------------------------------------------------------------------------------------------
>>> [EMAIL PROTECTED] 08-May-01 3:51:19 AM >>>
I need some advice on performance issues regarding tsm 4.1.2.0 running on
a aix 4.3.3 box.
I've been trying to optimize the network throughput, but without real
luck. Then I tried backing up the tsm server through lo0 and I ended up
with the following result
Total number of objects inspected: 49,295
Total number of objects backed up: 49,295
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 0
Total number of objects failed: 0
Total number of bytes transferred: 2.45 GB
Data transfer time: 546.68 sec
Network data transfer rate: 4,706.32 KB/sec
Aggregate data transfer rate: 2,041.05 KB/sec
Objects compressed by: 0%
Elapsed processing time: 00:03:00
which is not a fantastic throughput.
I'm backing up to a diskpool of ssa-disks (no raid) and i have a 30GB
database which has never been defragmented.
Is it a memory tuning issue?
Any suggestions are welcome.
Does anyone know of a new tivoli performance tuning guide? I have a (not
up to date) SP performance tuning guide.
Med venlig hilsen / Regards
Henrik Ursin Tlf./Phone +45 35878934
Fax +45 35878990
Email [EMAIL PROTECTED]
Mail: UNI-C
DTU, bygning 304
DK-2800 Lyngby
